linux-kernel - RE: condingstyle, was Re: utrace comments

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]

Message-ID: <001601c78c0b$deb12a30$294b82ce@stuartm>
Date:	Tue, 1 May 2007 12:15:00 -0400
From:	"Stuart MacDonald" <stuartm@...necttech.com>
To:	"'Satyam Sharma'" <satyam.sharma@...il.com>,
	"'Andrew Morton'" <akpm@...ux-foundation.org>
Cc:	"'Christoph Hellwig'" <hch@...radead.org>,
	"'Roland McGrath'" <roland@...hat.com>,
	"'Christoph Hellwig'" <hch@....de>, <linux-kernel@...r.kernel.org>,
	<linux-arch@...r.kernel.org>
Subject: RE: condingstyle, was Re: utrace comments

From: On Behalf Of Satyam Sharma
> readable and obvious at first glance itself. For example, consider:
               ^^^^^^^^^^^^^^^^^^^^^^^
> 
> 	if (veryverylengthycondition1 &&
> 		smallcond2 &&
> 		(conditionnumber3a ||
> 		condition3b)) {
> 		...
> 	}
> 
> versus

Whoops! You've got an unterminated if there, let me fix it up...

> 	if (veryverylengthycondition1) {
> 	    && smallcond2
> 	    && (conditionnumber3a
> 	        || condition3b)) {
> 		...
> 	}> 

From: On Behalf Of Scott Preece
> I still find the leading-operator style much more readable. The most
> important thing in reading a long, complex conditional is
> understanding the structure of the operators, not the operands.

Since there's a mix of pre-, post- and infix, the structure of the
operators _depends on_ the operands.

> However, there's a lot of difference of opinion on this (perhaps
> rooted in differences in cognition and reading behavior). For me it's
> not even close - expressions broken so the operators are at the head
> of the line snap into focus and those with operators at the ends of
> the lines look like undifferentiated goo. Since some of the style

I'm exactly opposite; the "uncorrected" line above is a typo because
there's no continuation item at the end of the line. I don't even see
the following lines because they are, by definition, not part of the
code I'm looking at. Leaving the operators at the end of the line I
easily see that it's a binary operator, and there's no second operand
so the next line must contain it, parse the next line as well.

Hm. I didn't realise this but the unspoken underlying factor for me is
the "one instruction per line" style. If you must break over multiple
lines, there must be a continuation item to indicate that. This is how
I detect missing semicolons.

..Stu

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