Can't we relax the 80 column line rule to something more comfortable?
These days descriptive variable/function names are much more valuable,
I think.
Just by looking at random examples in the tree, seems the 80 column
rule does more harm than good. I always find myself start shortening
names just to fit the line limit and not to need to line-wrap a statement.
We even use #defines sometimes to access simple structure members and
the like, only to fit that rule.
So, are we sure that 80 columns is still valuable, looking at the
side-effects of artificially shortended variable/function names and
line-wrapped statements, caused by this rule?
Thanks,
Kay
On 1/5/06, Kay Sievers <[email protected]> wrote:
> Can't we relax the 80 column line rule to something more comfortable?
Please don't.
I very often work in console (or xterm) and editing kernel code. Files
with lines >80 col. are quite annoying to have to scroll left/right in
and not being able to see the end of lines.
Also, very long lines are annoying to read even if they do fit on your
screen, I can easily fit code lines of 200 chars or more in a GUI
editor in X but IMO readability suffers compared to when that long
line is broken up into a few shorter pieces - less horizontal eye
movement.
> These days descriptive variable/function names are much more valuable,
> I think.
>
Short names can be descriptive too, and long names are not nice to
have to type all the time. Besides, if you need a long description of
a variable or function then use a comment don't try and encode
everything into the name.
> Just by looking at random examples in the tree, seems the 80 column
> rule does more harm than good. I always find myself start shortening
> names just to fit the line limit and not to need to line-wrap a statement.
Sure, if you name variables like "int temporary_place_holder" instead
of simply "int tmp" and similar, then 80cols are annoying, but I'd say
the problem there is not the line length limit but the name being
used.
Short and sweet is my preference.
> We even use #defines sometimes to access simple structure members and
> the like, only to fit that rule.
>
> So, are we sure that 80 columns is still valuable, looking at the
> side-effects of artificially shortended variable/function names and
> line-wrapped statements, caused by this rule?
>
IMHO it's a good rule and we should stick to it.
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
Hi,
On 1/5/06, Kay Sievers <[email protected]> wrote:
> Can't we relax the 80 column line rule to something more comfortable?
> These days descriptive variable/function names are much more valuable,
> I think.
I don't see the point, really. If your nesting is within reasonable
limits, long names are usually not a problem. And your nesting is too
deep, it should be fixed. Out of curiosity, what limit do you think
would work better to you?
Pekka
On Thu, 5 Jan 2006, Kay Sievers wrote:
> Can't we relax the 80 column line rule to something more comfortable?
Never ask about that on this ml. Some months ago I did the same
mistake and it resulted in a flamewar that lasted many days. :)
--
Giuliano.
Kay Sievers <[email protected]> wrote:
> Can't we relax the 80 column line rule to something more comfortable?
> These days descriptive variable/function names are much more valuable,
> I think.
The patches are sent by email, and it's recommended to not exceed the
76-character-limit within email.
--
Ich danke GMX daf?r, die Verwendung meiner Adressen mittels per SPF
verbreiteten L?gen zu sabotieren.
On Thu, Jan 05, 2006 at 03:32:28PM +0200, Pekka Enberg wrote:
> On 1/5/06, Kay Sievers <[email protected]> wrote:
> > Can't we relax the 80 column line rule to something more comfortable?
> > These days descriptive variable/function names are much more valuable,
> > I think.
>
> I don't see the point, really. If your nesting is within reasonable
> limits, long names are usually not a problem.
Well, it always feels silly, to line wrap manually like in this patch:
http://lkml.org/lkml/mbox/2005/12/2/219
And sometimes it would just be nice to have "len" called "buflen"
or whatever, but that makes things even worse with the 80's rule. :)
I just wanted to do some whitespace cleanup and add named prototypes
to include/linux/device.h but a lot of lines are already exceeding
80 columns and wrapping the lines would make the file even more
unreadable, that's why I was asking. :)
> And your nesting is too deep, it should be fixed.
It's not about nesting, if that's the reason, the number of tabs
should get a maximum specified instead.
> Out of curiosity, what limit do you think
> would work better to you?
Normal 80, but if it makes sense 120, then usually the editor will line
wrap, which is in most cases better to read than starting lines at
column 60.
Thanks,
Kay
>> And your nesting is too deep, it should be fixed.
>
>It's not about nesting, if that's the reason, the number of tabs
>should get a maximum specified instead.
>
Or we could have the tab width lowered, but I doubt
Linus would accept that :)
Jan
--
On 1/5/06, } <[email protected]> wrote:
> El Thu, 5 Jan 2006 14:27:23 +0100,
> Jesper Juhl <[email protected]> escribi?:
>
> > I very often work in console (or xterm) and editing kernel code. Files
> > with lines >80 col. are quite annoying to have to scroll left/right in
>
> I wonder why (we) people keeps working (and writing emails) with a 80
> cols limit - monitors are BIG these days and even the crappiest
> graphic card can do better than 80x25 even without using fbcon. Is not
I'm well aware that my hardware can easily do more than 80 columns,
but that's simply not as pleasant to read. Even in X I usually keep my
xterms to 80 columns and with a resonably large font so I don't have
to strain my eyes too much when reading.
> that breaking the 80-cols rules is annoying, working with such setups
> are painful even to run basic shell scripts. These days hardware can do
> better things than 80-col consoles even for console users.
>
It's not about hardware capabilities, it's about readability.
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
On Thursday 05 January 2006 13:02, Kay Sievers wrote:
> Can't we relax the 80 column line rule to something more comfortable?
> These days descriptive variable/function names are much more valuable,
> I think.
>
> Just by looking at random examples in the tree, seems the 80 column
> rule does more harm than good. I always find myself start shortening
> names just to fit the line limit and not to need to line-wrap a statement.
I've found myself drifting to and from favouring the 80 cols limit in my own
code. It's a good way of forcing yourself to refactor, which usually works
out nicely, and I've even managed to write Java that was mostly 80 cols
(which is a far bigger challenge than C due to the required preceding tab
depth for a method inside a class..)
> We even use #defines sometimes to access simple structure members and
> the like, only to fit that rule.
This is usually for multiple levels of dereferencing, and it really does help
readability.
> So, are we sure that 80 columns is still valuable, looking at the
> side-effects of artificially shortended variable/function names and
> line-wrapped statements, caused by this rule?
It's fairly redundant trying to answer this question without the opinion of
the people that really matter. I'd hazard a guess and say that if you ranked
kernel contributors by man-hours spent on the kernel, the top ten would all
think the 80 columns rule was critically important.
--
Cheers,
Alistair.
'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
On Thu, Jan 05, 2006 at 02:02:49PM +0100, Kay Sievers wrote:
> Can't we relax the 80 column line rule to something more comfortable?
OMG - The horror
--
[email protected]
SDF Public Access UNIX System - http://sdf.lonestar.org
On Thu, Jan 05, 2006 at 11:03:09PM +0100, Jan Engelhardt wrote:
> >> And your nesting is too deep, it should be fixed.
> >
> >It's not about nesting, if that's the reason, the number of tabs
> >should get a maximum specified instead.
> >
> Or we could have the tab width lowered, but I doubt
> Linus would accept that :)
In fact, one tab could be lowered, it's the first one. Nearly all code
has at least this tab which is not very useful and would not affect
readability if reduced to 2 or 4. But it will be difficult to maintain
a variable tab width, not to mention the alignment problem on the
second tab.
BTW, if 80 is not enough, simply consider that one tab is exactly one
character ( '\011' ) and you will be able to put more, but I doubt
your code will be accepted ;-)
Willy
>> >It's not about nesting, if that's the reason, the number of tabs
>> >should get a maximum specified instead.
>> >
>> Or we could have the tab width lowered, but I doubt
>> Linus would accept that :)
>
>In fact, one tab could be lowered, it's the first one. Nearly all code
>has at least this tab which is not very useful and would not affect
>readability if reduced to 2 or 4. But it will be difficult to maintain
>a variable tab width, not to mention the alignment problem on the
>second tab.
>
Oh every editor can be patched. Since 4-(wide)-tabs (in general, not just
at the start) and esp. 2-tabs are dishonored (CodingStyle: "There are
heretic movements that try to make indentations 4 (or even 2!)"), 6-tabs
and 3-tabs could be tried. Ahem :).
Jan Engelhardt
--
>> Can't we relax the 80 column line rule to something more comfortable?
>
>OMG - The horror
>
Well, I do not see anything wrong with having a very few lines
(max 2%) exceeding 80 just because a trailing ) or ; won't fit and would
go into column 81. (I do however limit myself quite strictly, max is 83,
and that's reall only the corner of corner cases.)
Jan Engelhardt
--
>> Can't we relax the 80 column line rule to something more comfortable?
>> These days descriptive variable/function names are much more valuable,
>> I think.
>
>The patches are sent by email, and it's recommended to not exceed the
>76-character-limit within email.
>
That won't work. There is always something that makes it impossible to have
an entire mail with patch fit in 76 cols (unless you uuencode), simply
because the diff headers like the ===, --- and +++ lines may be longer, the
more even when a timestamp is provided.
However, I do not vote against timestamps, but diff puts them automatically
in and I am fine with all that.
Jan Engelhardt
--