konglu@xxxxxxxxxxxxxxx writes:
> Thomas Rast <trast@xxxxxxxxxxxxxxx> a écrit :
>
>> Leila <muhtasib@xxxxxxxxx> writes:
>>
>>>> The structure is
>>>> if (...) {
>>>> /*code*/
>>>> } else {
>>>> /*code*/
>>>> }
>>>>
>>>> Do not forget braces in the "else" part as the firt block needs it.
>>>
>>> I was under the impression that one liners didn't require parenthesis
>>> according to the style guidelines. I didn't realize that if the 'if'
>>> required it, then the else required it. I will make that change and
>>> remember it for the future. Thanks!
>>
>> 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.
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).
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
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