Eric Wong <[email protected]> writes:
>> > Not a big deal (no need to resend for this one alone), but let's
>> > make the above properly formatted, i.e.
>> >
>> > if (ce_stage(ce)) {
>> > ...
>> > } else {
>> > ...
>> > }
>>
>> Do I understand correctly that your objections is against having the curly
>> brace before the "else" on its own line?
>>
>> If so, when did our coding style change? I vividly remember that we
>> strongly favored putting the "else" on a new line after a closing brace,
>> to make diffs nicer in case the braces were removed or added.
>
> AFAIK, Linux kernel CodingStyle has always been what Junio
> suggested (just w/o the trailing spaces :),
> and we inherit from that.
What Eric said.
While I admit that I sometimes break line between "}" and "else {"
by inertia when I am being careless and get caught by checkpatch.pl
myself, I do not recall trying to justify it; you probably may
remember somebody else saying that, but I don't recall anybody
making that argument on the list, and more importantly I don't
recall us making that our style based on that argument.
The only two and half kinds of warnings we knowingly ignore from
scripts/checkpatch.pl in the Linux kernel source tree are:
* "Avoid typedefs." We do avoid making graduitous use of typedef to
hide a structure behind a type and pretty much limit ourselves to
use it for (callback) function types, though.
* "We've never heard of Helped-by/Mentored-by footers"; well,
kernel folks may not, but we have ;-)
* "No spaces for bitfield width". This may not be justifyable, but
the majority of our bitfield widths are defined in the way not
blessed by checkpatch.pl checker.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
