Thomas Rast <trast@xxxxxxxxxxxxxxx> writes:
>>> It's not required, there's plenty of precedent, even one case within
>>> wt-status.c, of '} else'. Try running
>>>
>>> git grep '} else$'
>>
>> It's not because "there's plenty of precedent" that we should not try
>> to improve the format of the code. That's why there're coding style
>> rules so that we can keep the improvements consistent.
>
> Yeah, and the rules (Documentation/CodingGuidelines) say
>
> - We avoid using braces unnecessarily. I.e.
>
> if (bla) {
> x = 1;
> }
>
> 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.
>
> I'm not the one who wrote them, but I'm taking the last sentence to mean
> that you should not put the braces unless the omission will break the
> vertical alignment of the 'else if' chain.
The guidelines are not black-and-white, but the spirit is to suggest
avoiding unnecessary braces around single statement blocks while
allowing exception when consistency across if/else if/... cascade
makes the result easier to read.
> BTW, there are plenty of cases in git where it is better to stick to the
> existing style of the file instead of the CodingGuidelines, unless you
> are willing to clean up the file first (and nobody else works on it).
Yes.
--
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