Thread (1 message) 1 message, 1 author, 2016-08-08

Re: [PATCH v5 4/9] status: collect per-file data for --porcelain=v2

From: Junio C Hamano <hidden>
Date: 2016-08-08 01:58:29

Eric Wong [off-list ref] writes:
quoted
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help