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