linux-kernel - Re: Merging of completely unreviewed drivers

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:	Sun, 24 Feb 2008 13:56:15 +1030
From:	David Newall <davidn@...idnewall.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Pavel Machek <pavel@....cz>, Krzysztof Halasa <khc@...waw.pl>,
	Jeff Garzik <jeff@...zik.org>, Adrian Bunk <bunk@...nel.org>,
	Roland Dreier <rdreier@...co.com>,
	Glenn Streiff <gstreiff@...Effect.com>,
	Faisal Latif <flatif@...Effect.com>,
	linux-kernel@...r.kernel.org, general@...ts.openfabrics.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Greg Kroah-Hartman <greg@...ah.com>
Subject: Re: Merging of completely unreviewed drivers

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.)
--
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/