Hi,
Leila Muhtasib wrote:
> --- a/Documentation/CodingGuidelines
> +++ b/Documentation/CodingGuidelines
> @@ -117,9 +117,26 @@ For C programs:
>
> is frowned upon. A gray area is when the statement extends
> over a few lines, and/or you have a lengthy comment atop of
> - it. Also, like in the Linux kernel, if there is a long list
> - of "else if" statements, it can make sense to add braces to
> - single line blocks.
> + it. Also, like in the Linux kernel, if one of the
> + "if/else if/else" chain has a multiple statement block, use {}
> + even for a single statement block in that chain. And "else"
> + should come on the same line as the closing "}" of its "if" block.
I don't think that's quite accurate. Current best practice in both
git and the Linux kernel is a little looser than that.
> +
> + //correct
> + if (bla) {
> + x = 1;
> + ...
> + } else {
> + x = 2;
> + }
True.
> +
> + //incorrect
> + if (bla) {
> + x = 1;
> + ...
> + }
> + else
> + x = 2;
Also true. But:
/* correct */
if (bla) {
x = 1;
...
} else
x = 2;
And:
If you have a long "if" with a one-line "else", consider whether you
are needlessly keeping the reader in suspense about something simple.
It might be more pleasant to read with the exceptional case up front:
if (!bla) {
x = 2;
} else {
x = 1;
...
}
This is especially true when the exceptional case returns or exits.
if (bla && no_bla)
return error("--blah and --no-blah cannot be used together");
x = 1;
...
Hope that helps,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html