From: Jesper Juhl <jesper.juhl@gmail.com>
To: Kay Sievers <kay.sievers@vrfy.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 80 column line limit?
Date: Thu, 5 Jan 2006 14:27:23 +0100 [thread overview]
Message-ID: <9a8748490601050527x407ff85dref45774d5eb131d9@mail.gmail.com> (raw)
In-Reply-To: <20060105130249.GB29894@vrfy.org>
On 1/5/06, Kay Sievers <kay.sievers@vrfy.org> 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 <jesper.juhl@gmail.com>
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
next prev parent reply other threads:[~2006-01-05 13:27 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-05 13:02 Kay Sievers
2006-01-05 13:27 ` Jesper Juhl [this message]
[not found] ` <20060105154330.da1016fc.grundig@teleline.es>
2006-01-05 22:27 ` Jesper Juhl
2006-01-05 13:32 ` Pekka Enberg
2006-01-05 21:14 ` Kay Sievers
2006-01-05 22:03 ` Jan Engelhardt
2006-01-06 5:52 ` Willy Tarreau
2006-01-06 7:09 ` Jan Engelhardt
2006-01-05 13:43 ` Giuliano Pochini
2006-01-05 23:02 ` Alistair John Strachan
2006-01-06 1:34 ` Jim Nance
2006-01-06 7:12 ` Jan Engelhardt
[not found] <5rD2D-xs-11@gated-at.bofh.it>
2006-01-05 18:08 ` Bodo Eggert
2006-01-06 7:14 ` Jan Engelhardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9a8748490601050527x407ff85dref45774d5eb131d9@mail.gmail.com \
--to=jesper.juhl@gmail.com \
--cc=kay.sievers@vrfy.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®