diff options
author | Thomas Haller <thaller@redhat.com> | 2022-01-11 09:59:01 +0100 |
---|---|---|
committer | Thomas Haller <thaller@redhat.com> | 2022-01-11 14:30:33 +0100 |
commit | 9ab22dbc805c33f160e23793aa846b716d479e09 (patch) | |
tree | 56f522fe8bbe7f3dc57cbac1c44ecf4d462d0c8e /COPYING.LGPL | |
parent | d5f917e702dfa9fada6c8ac19a09a3bacd7dbbb6 (diff) | |
download | NetworkManager-9ab22dbc805c33f160e23793aa846b716d479e09.tar.gz |
CONTRIBUTING: clarify on the use/lack of curly braces around blocks
This is the style we have ever since. Spell it out. With the difference
that now single line statements may have braces.
Recently we were already sloppy about allowing curly braces for single line
statements. Maybe there was a point in that. Imagine you start with:
if (condition)
call(some, parameter);
Afterwards you change the code so that the line becomes too long and
clang-format wraps the line (requiring you to add braces):
if (condition) {
call(some,
call_another_function(hey));
}
The problem now is that this diff is larger than it would have been, if
you added curly braces from the start. Also, it means you have to go
back and forth to add/remove these braces, as clang-format reformats the
code.
Also, if you have if-else-if blocks, then mixing multi line statements
with single line statements is also cumbersome, because when something
needs to change, the diff is may be larger (and the change more
cumbersome).
So it might be convenient to just always add the braces, and the
documented style now allows for that.
Diffstat (limited to 'COPYING.LGPL')
0 files changed, 0 insertions, 0 deletions