linux-kernel - Re: [PATCH 1/2] Staging; bcm/CmHost.c: Style cleanup

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: <20120128072417.GU3294@mwanda>
Date:	Sat, 28 Jan 2012 10:24:17 +0300
From:	Dan Carpenter <dan.carpenter@...cle.com>
To:	Jesper Juhl <jj@...osbits.net>
Cc:	devel@...verdev.osuosl.org,
	Lucas De Marchi <lucas.demarchi@...fusion.mobi>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	linux-kernel@...r.kernel.org,
	"Justin P. Mattock" <justinmattock@...il.com>,
	Ilia Mirkin <imirkin@...m.mit.edu>
Subject: Re: [PATCH 1/2] Staging; bcm/CmHost.c: Style cleanup

On Sat, Jan 28, 2012 at 12:43:39AM +0100, Jesper Juhl wrote:
> On Wed, 25 Jan 2012, Dan Carpenter wrote:
> 
> > This is probably going to need to be redone on top of the other bcm
> > cleanup patches anyway.
> > 
> If that turns out to be so, well, so be it. I was not aware of other 
> patches, so my bad...
> 
> > On Tue, Jan 24, 2012 at 11:46:31PM +0100, Jesper Juhl wrote:
> > > +		pstClassifierEntry->ucDestPortRangeLength
> > > +			= psfCSType->cCPacketClassificationRule.u8ProtocolDestPortRangeLength/4;
> > 
> > Put the equals on the first line when you break something up like
> > this. Also the real fix here is to choose shorter and better names
> > than "cCPacketClassificationRule.u8ProtocolDestPortRangeLength".
> > 
> > If you're breaking up a condition normally the && or || go on the
> > first line as well.
> > 	if (foo &&
> > 	    bar &&
> > 	    baz) { ...
> > 
> > Although that's not in CodingStyle so it's not a "redo the patch"
> > situation.
> > 
> As you say, "not in CodingStyle", so I guess it's down to your personal 
> preference vs my personal preference vs what's most common in the kernel 
> vs maintainers preference.
> 
> I did it the way I did for a reason.
> I personally find that if one puts the '=', '==', '&&', '||', '+', 
> <whatever> at the end of each line on a multi-line statement, then they 
> are easy to overlook when just reading the code casually. If, however, one 
> puts them at the start of each line, they stand out and are easier to see 
> (harder to miss). That's why I did as I did. You may not agree, but at 
> least now you know my reason for doing it the way I did.
> 

The '=' certainly should go on the first line.  That one doesn't
need to be in CodingStyle because it's just obvious.  ;)  Anyway it
is the overwhelmingly prefered way in the kernel with 31449 cases
on the first line and 603 on the second.

For the others, I don't care, but in the kernel the clear preference
is to put them on the first line.  I've redone at least one patch
because someone complained about && placement.

regards,
dan carpenter


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