From: David Newall <davidn@davidnewall.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Pavel Machek <pavel@ucw.cz>, Krzysztof Halasa <khc@pm.waw.pl>,
Jeff Garzik <jeff@garzik.org>, Adrian Bunk <bunk@kernel.org>,
Roland Dreier <rdreier@cisco.com>,
Glenn Streiff <gstreiff@NetEffect.com>,
Faisal Latif <flatif@NetEffect.com>,
linux-kernel@vger.kernel.org, general@lists.openfabrics.org,
Andrew Morton <akpm@linux-foundation.org>,
Greg Kroah-Hartman <greg@kroah.com>
Subject: Re: Merging of completely unreviewed drivers
Date: Sun, 24 Feb 2008 13:56:15 +1030 [thread overview]
Message-ID: <47C0E3D7.50901@davidnewall.com> (raw)
In-Reply-To: <alpine.LFD.1.00.0802230913380.21332@woody.linux-foundation.org>
Linus Torvalds wrote:
> On Sat, 23 Feb 2008, David Newall wrote:
>
>> Do you actually get 80 columns wide on it?
>>
>
> Do people really care that deeply?
> ...
> And do I find lines longer than 80 charactes unreadable? Hell no.
>
I care, yes. I've found my code looks much prettier, with attendant
improvement in ease of understanding, since I stopped being so anal
about 80 columns. The width of the code, that is first to last
non-blank on each line, is about the same, not because I work to keep
it narrow, but because most statements just are narrow. Sometimes I do
get really wide statements, for example when using deep data structures,
especially as parameters in procedure calls, and this is easier to read
than having to break the line.
I honestly think the reason we used to insist on lines less than 80
characters was because on an 80 character screen, you get slightly
better readability by choosing where to break each line than simply
letting the hardware do it. We don't have the physical limit any more,
so we don't need to impose it structurally.
It's about readability, and with due respect, people who've never tried
it aren't qualified to comment.
> which talks more about what matters - too deep indentation.
What's too deep? Is the following too deep? It's common enough, other
than my refusal to relax consistent indenting style for switch bodies.
The code is readable, and breaking it into multiple procedures just to
de-indent is often impossible, and rarely readable. With a strict 80
character limit, the meat in the sandwich is left with only 20 or so
characters in which to fit. Add a nested switch, and there's virtually
no space left for code.
123456789012345678901234567890123456789012345678901234567890123456 (70)
int procedure(param list)
{
switch (condition)
{
case value:
if (another_condition)
{
if (variant)
meat_in_sandwich;
} else {
code;
}
case value2:
switch (sub_condition)
{
case sub_value:
if (final_test)
{
something(
NULL,
1,
"two");
}
}
}
}
(Yes, I know, "we don't indent 'case' because it consumes too much
room." That's inconsistent with the rest of normal indenting style, and
a poor excuse to keep within an obsolete and unnecessary restriction.)
next prev parent reply other threads:[~2008-02-24 4:34 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-19 22:59 [2.6 patch] infiniband/hw/nes/nes_verbs.c: fix off-by-one Adrian Bunk
2008-02-20 4:23 ` [ofa-general] " Roland Dreier
2008-02-20 5:57 ` Adrian Bunk
2008-02-20 23:21 ` Roland Dreier
2008-02-20 23:27 ` Glenn Streiff
2008-02-21 12:39 ` Glenn Streiff
2008-02-21 15:49 ` Adrian Bunk
2008-02-21 20:28 ` Roland Dreier
2008-02-21 21:01 ` Merging of completely unreviewed drivers Adrian Bunk
2008-02-21 21:09 ` Roland Dreier
2008-02-21 21:14 ` Linus Torvalds
2008-02-21 22:33 ` Alexey Dobriyan
2008-02-21 22:43 ` Greg KH
2008-02-21 22:57 ` Jeff Garzik
2008-02-21 22:58 ` Alexey Dobriyan
2008-02-21 23:31 ` Jan Engelhardt
2008-02-21 23:38 ` Krzysztof Halasa
2008-02-21 23:31 ` Alan Cox
2008-02-22 0:29 ` Adrian Bunk
2008-02-21 23:41 ` Jeff Garzik
2008-02-22 0:05 ` Krzysztof Halasa
2008-02-22 0:44 ` Jeff Garzik
2008-02-22 2:02 ` Krzysztof Halasa
2008-02-22 10:04 ` Alan Cox
2008-02-22 18:45 ` Pavel Machek
2008-02-22 22:44 ` Krzysztof Halasa
2008-02-23 9:43 ` Pavel Machek
2008-02-23 12:38 ` David Newall
2008-02-23 15:25 ` Pavel Machek
2008-02-24 3:18 ` David Newall
2008-02-23 17:33 ` Linus Torvalds
2008-02-24 3:26 ` David Newall [this message]
2008-02-24 4:47 ` Linus Torvalds
2008-02-23 13:58 ` Krzysztof Halasa
2008-02-22 1:46 ` David Newall
2008-02-22 2:06 ` Al Viro
2008-02-22 2:23 ` Krzysztof Halasa
2008-02-22 3:13 ` Al Viro
2008-02-22 22:28 ` Krzysztof Halasa
2008-02-24 7:47 ` Jörn Engel
2008-02-24 14:47 ` Krzysztof Halasa
2008-02-22 3:13 ` Linus Torvalds
2008-02-22 6:29 ` [ofa-general] " Junio C Hamano
2008-02-22 9:02 ` Adrian Bunk
2008-02-22 6:37 ` Ray Lee
2008-02-23 15:31 ` Jan Engelhardt
2008-02-24 3:22 ` David Newall
2008-02-22 22:37 ` Krzysztof Halasa
2008-02-22 12:29 ` [ofa-general] " Bart Van Assche
2008-02-22 14:25 ` David Newall
2008-02-22 15:17 ` Peter Zijlstra
2008-02-22 16:48 ` John W. Linville
2008-02-22 22:59 ` Krzysztof Halasa
2008-02-22 23:14 ` Al Viro
2008-02-22 15:48 ` John W. Linville
2008-02-22 18:54 ` Ingo Molnar
2008-02-22 19:11 ` [ofa-general] " Bart Van Assche
2008-02-22 19:20 ` Jeff Garzik
2008-02-22 19:44 ` Greg KH
2008-02-21 21:30 ` Greg KH
2008-02-22 1:06 ` Adrian Bunk
2008-02-21 22:08 ` Arjan van de Ven
2008-02-21 22:33 ` Jeff Garzik
2008-02-21 23:40 ` Adrian Bunk
2008-02-22 18:40 ` Pavel Machek
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=47C0E3D7.50901@davidnewall.com \
--to=davidn@davidnewall.com \
--cc=akpm@linux-foundation.org \
--cc=bunk@kernel.org \
--cc=flatif@NetEffect.com \
--cc=general@lists.openfabrics.org \
--cc=greg@kroah.com \
--cc=gstreiff@NetEffect.com \
--cc=jeff@garzik.org \
--cc=khc@pm.waw.pl \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=rdreier@cisco.com \
--cc=torvalds@linux-foundation.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