Message-ID: <7004b08e0912181315n1894ca90m8752b57708cf55eb@mail.gmail.com>
Date:	Fri, 18 Dec 2009 15:15:03 -0600
From:	kevin granade <kevin.granade@...il.com>
To:	Mikulas Patocka <mpatocka@...hat.com>
Cc:	Krzysztof Halasa <khc@...waw.pl>, Valdis.Kletnieks@...edu,
	Paul Mundt <lethal@...ux-sh.org>, linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Alasdair G Kergon <agk@...hat.com>, dm-devel@...hat.com
Subject: Re: [PATCH] Drop 80-character limit in checkpatch.pl

On Fri, Dec 18, 2009 at 10:43 AM, Mikulas Patocka <mpatocka@...hat.com> wrote:
>> Note: I'm not specifically arguing for keeping the 80-column rule, the
>> project I work on uses 100 columns, and that's quite workable, but I
>> haven't had any problem working with 80 columns as a limit either.  I
>> do however think that just removing the limit without replacing it
>> with something better is a bad idea.
>>
>> -Kevin Granade
>
> But think what happens when someone views that 100-char code on 80-char
> terminal (or for example 94-char, that I used for some times too) ---
> every second line will be wasted with just 20 characters on the left. On
> the other hand, if you have unlimited line length, it will look better on
> 80-char terminal.

1. I think that is why the limit is at 80 characters, so it's at the
lowest common denominator of screen and will not wrap at all.
(actually wasn't the original limit an email mangling issue?)
2. Aside from choosing the specific limit of 80, I don't think line
wrapping is a major goal of the line length limitation, as I said
before it is a heuristic that is indicative of BAD CODE.  The wrapping
issue is somewhat incidental.
3. I don't trust automated line-wrapping to provide readable code
anyway.  People I think will be much better at doing this, for
example, a common issue is with formatted string functions like scanf.
 A person will (ok, should) know to preferentially wrap after the
format string, and if they are really being nice can generalize about
other things, like name-value pairs:

scanf("%d,%d;%d,%d;%d,%d",
         key1, value1,
         key2, value2,
         key3, value3);

whereas automated wrapping will only know about a limited number of
rules, generally purely syntax-based: (yes, this is somewhat
contrived, but I think it illustrates the kind of limitation I'm
talking about.)

scanf("%d,%d;%d,%d;%d,%d", key1, value1, key2,
         value2, key3, value3);

But this is all really beside the point, if you really want to you can
write a text editor that will unwrap the text for you, and then
re-wrap it exactly how you want it.  I don't think this would be all
that much harder than one that could intelligently wrap the lines in
the first place.

The point I keep coming back to is to follow the *important* coding
guidelines, like avoiding excessive nesting and properly factoring
your code into sub-modules (macros, functions, inlined functions, etc.
as appropriate.)  The line limit acts as a warning that you are
probably doing something wrong, just shortening the line in question
is not the answer.

Other incidental issues:
"wasting lines" - Don't care, factor properly and a single unit of
code should fit in a screenfull or two.
"effort wasted manually wrapping lines" - Also don't care, if you
think the text editor should be smart enough to wrap lines
intelligently, just use it to do it for you.  (hint: they're generally
not actually that smart).  Also consider the alternative there, if
multi-hundred character lines are the norm, just how easy are the
contents of those lines to manipulate?

>
> Mikulas
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists