Cc: Pavel Machek <pavel@...>, Krzysztof Halasa <khc@...>, Jeff Garzik <jeff@...>, Adrian Bunk <bunk@...>, Roland Dreier <rdreier@...>, Glenn Streiff <gstreiff@...>, Faisal Latif <flatif@...>, <linux-kernel@...>, <general@...>, Andrew Morton <akpm@...>, Greg Kroah-Hartman <greg@...>
Do people really care that deeply?
I still sometimes use small terminal windows - for a while I had my
default terminal come up as 100x40, but I'm back to the standard 80x24,
and while I often resize them, I certainly don't always.
And do I find lines longer than 80 charactes unreadable? Hell no.
Quite frankly, on a 80x24 display, I'll take long lines over split-up ones
*any* day. For things like doing "git grep xyzzy", I'd *much* rather get
the occasional long line that wraps (or, if I'm in "less -S", that I have
to press right-arrow to see), than see just a meaningless fragment because
somebody decided that they should always fit in 80 characters.
So *consistently* long lines are the problem, not the occasional one. The
occasional one is likely more readable as it is, than split up.
Here's an example from code that actually looks pretty good in general:
static unsigned long
calc_delta_mine(unsigned long delta_exec, unsigned long weight,
struct load_weight *lw)
and look around that function in general: it's doesn't match the coding
standard, but also compare the output of
git grep calc_delta_mine
with the output of something like
git grep update_load_sub
which actually shows you what the calling convention is.
So putting that long function definition on one line would make it a
108-character line or somethign like that, but it would have advantages
too. It would have advantages for anything that is line-based (I use
grep for *everything*, but maybe I'm just odd), but it would also
actually be more readable for the people who have bigger windows.
But my point is, some of those advantages remain even with small
terminals, and quite often the downsides aren't even all that huge.
Most editors wrap or chop the line according to your preferences (mine
are personally to chop), and if it's a fairly uncommon thing, those
downsides shrink further.
Is 108 characters perhaps *too* long? In the above case it probably is,
since the downside of splitting the patch is pretty small (it's a static
function, only used in that file, the "grep" argument is weak, yadda
yadda). But I'm just saying that it's not 100% obvious *even*if* you're
on a 80x24 terminal, and in some other cases the downside of splitting
the line can be much bigger (strings or more spread-out function calls
and declarations etc).
The line length problem would probably be better attacked as something
more akin to the rule
- do a rolling window of <n> last non-empty lines (n ~ 15 or so)
- if more than <m> of those lines were longer than 72 charactes,
somethign is wrong (m ~ 5 or so).
which talks more about what matters - too deep indentation. And also
attacks the problem that is really relevant: it's that kind of code that
ends up being unreadable because so *much* of it is cut off or wrapped.
Linus
--
