Messages in this thread | | | Date | Thu, 9 Apr 2009 08:00:18 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [PATCH] ptrace: checkpatch fixes |
| |
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
| |