Re: [PATCH] ptrace: checkpatch fixes

[Linus Torvalds <torvalds@linux-foundation.org>]

On Thu, 9 Apr 2009, Ingo Molnar wrote:
> 
> We should perhaps introduce an too-deep-indentation warning: any 
> function with "[;{}]$" lines of 4 tabs in a row is already suspect 
> IMHO. At 5 it's definitely crazy and ugly.
> 
> This would be a very efficient function-length reductor: it cannot 
> be worked around via line wraps.

People would start using spaces to try to work around it instead, which is 
a worse cure than the problem.

Also, the thing is, a long _individual_ line is not a problem even if you 
have a 80-column terminal. Sane editors will have a marker for "this line 
continues", and even if you have an insane editors that doesn't do that, 
it's pretty obvious - and if you really care about the end of that 
_particular_ line (most of the time you don't), you can just move to that 
line.

So if you have a couple of long lines occasionally, that's not a huge 
problem. In fact, that's why I hate splitting lines so much: the "false 
indentation" that a line split causes is generally much more confusing 
visually (not so much in something like a function header, but often very 
much so inside the code itself).

> It would also be wonderful to warn about bad 80 columns 'fixes' - 
> i've seen way too many perfectly fine cleanups damaged by ugly 
> line-wrapping solutions.

The thing is, it's very hard to warn about those. You need more 
understanding than your average perl-script can ever get.

> We could also up the limit to 90 or 100 columns. My terminals are at 
> 90 columns and that's still pretty ergonomic.

I tend to start out with a 80x24 and just resize it, and end up at some 
random value. It's usually in the 90x40 range for me. But I do want the 
code to be perfectly _readable_ in a 80x24 window, and quite frankly, if 
you look at something like kernel/ptrace.c, it really generally is.

So sure, that "int ptrace_readdata()" line is longer than that, and won't 
show completely. But you don't miss any huge glaring code issues even in 
the truncated mode. In fact, if I try to use 80x24, my biggest issue will 
inevitably be not the 80 part, but the 24 part. 

IOW, I think there is much more reason to hate long _functions_ than there 
is reason to hate long lines. Both cause you to scroll. The long function 
where there is action over more than 24 lines happens a lot more.

					Linus