From: "John W. Linville" <linville@tuxdriver.com>
To: David Newall <davidn@davidnewall.com>
Cc: Bart Van Assche <bart.vanassche@gmail.com>,
Krzysztof Halasa <khc@pm.waw.pl>, Adrian Bunk <bunk@kernel.org>,
Greg Kroah-Hartman <greg@kroah.com>,
Roland Dreier <rdreier@cisco.com>,
linux-kernel@vger.kernel.org, general@lists.openfabrics.org,
Andrew Morton <akpm@linux-foundation.org>,
Glenn Streiff <gstreiff@neteffect.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Faisal Latif <flatif@neteffect.com>
Subject: Re: [ofa-general] Re: Merging of completely unreviewed drivers
Date: Fri, 22 Feb 2008 10:48:43 -0500 [thread overview]
Message-ID: <20080222154843.GC3067@tuxdriver.com> (raw)
In-Reply-To: <47BEDB3F.4090100@davidnewall.com>
On Sat, Feb 23, 2008 at 12:55:03AM +1030, David Newall wrote:
> Bart Van Assche wrote:
> > There is a reason to limit line length: scientific research has shown
> > that readability of regular texts is optimal for a line length between
> > 55 and 65 characters.
>
> Putting aside the point that we're talking code, not regular text, I've
> heard that said before and I don't think it's quite like that. Perhaps
> the numbers you said might assume various things such as the width of
> the eye's field of view, the distance to the image and the size of each
> character?
I'm sure all those assumptions are baked-in to the estimate. Yet the
fact remains that people's eyes are only so good and most people will
be reading at similar distances from the screen. So I don't see any
reason to invalidate those assumptions. FWIW, I find reading longer
lines to be painful -- it is easier to loose one's place in the text.
I would also echo a point Jeff Garzik made elsewhere that it is often
beneficial to have multiple windows oppen side-by-side. Longer lines
makes it harder to do that in a useful way. Instead the lines either
wrap or just trail off the screen. See the output of sdiff for how
this limits usefulness.
> > My experience is that the readability of source
> > code decreases when the lines are very long (more than 160
> > characters).
>
> The point is that the width, excluding leading and trailing white space,
> is what really matters. Even deeply indented code can be a snap to
> understand if you don't have to fight artificial line breaks. And we've
> got a much wider -- and taller! -- space available than we had in the
> old 80x24 (and 80x1) days.
I'm not sure deeply indented code is ever a snap to understand.
And FWIW, I'd rather deal with "artificial" line breaks than parameter
lists that just stream off the side of the page. The line breaks
make long parameters lists easier to digest. I'll sacrifice the
occasional odd breakage of a long string.
John
--
John W. Linville
linville@tuxdriver.com
next prev parent reply other threads:[~2008-02-22 16:03 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
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 [this message]
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=20080222154843.GC3067@tuxdriver.com \
--to=linville@tuxdriver.com \
--cc=akpm@linux-foundation.org \
--cc=bart.vanassche@gmail.com \
--cc=bunk@kernel.org \
--cc=davidn@davidnewall.com \
--cc=flatif@neteffect.com \
--cc=general@lists.openfabrics.org \
--cc=greg@kroah.com \
--cc=gstreiff@neteffect.com \
--cc=khc@pm.waw.pl \
--cc=linux-kernel@vger.kernel.org \
--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