linux-kernel - Re: coding style for long conditions

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, 06 Apr 2007 21:50:23 +0000
From:	Zan Lynx <zlynx@....org>
To:	Roland Dreier <rdreier@...co.com>
Cc:	David Brownell <david-b@...bell.net>,
	Stefan Richter <stefanr@...6.in-berlin.de>,
	Jan Engelhardt <jengelh@...ux01.gwdg.de>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	Tony Lindgren <tony@...mide.com>, linux-kernel@...r.kernel.org
Subject: Re: coding style for long conditions

On Fri, 2007-04-06 at 14:38 -0700, Roland Dreier wrote:
[snip]
> If you have a git tree handy, you can do "git show 68380b58" and see
> that Linus himself wrote:
> 
> 	if (get_wq_data(work) == cwq
> 	    && work_pending(work)
> 	    && !list_empty(&work->entry)) {
> 
> I have to admit that I would have put the &&s at the ends of the
> previous lines rather than where Linus put them, but... egads!  Linus
> put spaces before the &&s to line them up nicely!

My favorite form uses only tabs and would make that look like:
	if(
		get_wq_data(work) == cwq &&
		work_pending(work) &&
		!list_empty(&work->entry)
	) {
		...
		...
	}

Putting the && at the front would be OK with me too, it does make them
more obvious and easier to find.

I don't find too many people who like my style but that's OK.  I think
it makes everything a lot easier to read and everything lines up with
8-space tabs or 2 or 3 space tabs.  Plus, reformatting other people's
code gives me a good chance to read it as I go. :-)
-- 
Zan Lynx <zlynx@....org>

Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)