lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 22 Feb 2008 16:17:17 +0100
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	David Newall <davidn@...idnewall.com>
Cc:	Bart Van Assche <bart.vanassche@...il.com>,
	Krzysztof Halasa <khc@...waw.pl>,
	Adrian Bunk <bunk@...nel.org>,
	Greg Kroah-Hartman <greg@...ah.com>,
	Roland Dreier <rdreier@...co.com>,
	linux-kernel@...r.kernel.org, general@...ts.openfabrics.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Glenn Streiff <gstreiff@...effect.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Faisal Latif <flatif@...effect.com>
Subject: Re: [ofa-general] Re: Merging of completely unreviewed drivers


On Sat, 2008-02-23 at 00:55 +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?

Not in my experience.

> >  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 have 2 24" screens running at 1920x1200 with X forced to 75dpi and use
a 8pt Monospace font. (Yes, I can read that from more than 3ft away)

Using a fullscreen gvim (without the icons, but with the menu) with 3
vertical splits gives me 4 columns of 113 rows and 95 chars.

So, yes, I have the screen estate for very long lines, but I find that
long lines require more effort to read (that very much includes leading
whitespace). Also, since long lines are rare (and they should be, if you
nest too deep you have other issues) accommodating them would waste a
lot of screen estate otherwise useful for another column of text.

Even with e-mail, I can easily show over 200 characters wide with a
large font (say 11pt) but find it harder to read emails that don't
nicely wrap at 78. So much so that I often find myself not reading the
mail, or restyling it if I find it important enough to read anyway.

Please, lets keep the 80 as a guideline, and not trip over the
occasional lines that exceed it in good style (read: wrapping them would
indeed give uglier code)

--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ