Re:Linux kernel coding style
by nolemurs on Monday March 27, 2017 @09:59PM
(#13973435)
Other people are complaining about the 80 character line limit, but personally, I'm shocked and dismayed by the preference for no braces on `if` statements with single line blocks. It is so easy to accidentally add a line to what looks like an `if` block (but isn't since there are no braces), and then you have a bug that is visually very difficult to spot. I'm pretty strongly against this rule!
[ Parent
| on HN ]
I don't get what "what looks like an `if` block" is. In a no-brace if, the statement that follows is indented. The next line after that is not indented. So the indented statement obviously belong to the if.
The issue that comes up is when you go to add a line to that 'block' it's easy not to notice that it's not actually a block, just a single statement. Then you add another indented line, and now you've got something that looks a lot like a block, but isn't at all!
Of course, as others have pointed out, with some sort of reasonable linting setup or with compiler warnings, you'll probably catch the bug (unless macros are involved), but even so, I feel having something that looks like a block but isn't, adds cognitive load for little benefit.
This works well in languages where whitespace matters
I found it interesting that systemd actually requires this behaviour:
https://github.com/systemd/systemd/blob/master/CODING_STYLE#...
I once found a particularly confusing use of this style here:
https://github.com/erlang/otp/blob/master/erts/epmd/src/epmd...
Re:Linux kernel coding style
by Light2Yellow on Monday March 27, 2017 @11:03PM
(#13973715)
I cannot agree more. I'm trying to enforce the braces as much as possible because one always adds a statement here and there and obviously forgets to put them (for debugging purposes for example).
This is a very big drawback, as Linux is positioning itself as a programmer-friendly and "simplistic" C project.
> It is so easy to accidentally add a line to what looks like an `if` block
But it is also so easy to catch that automatically (and in fact, gcc and clang will flag this as an error for you with the right incantation, and refuse to compile), that it is stupid to leave it to 50 different committers all avoiding accidents.
Be careful when using macros however: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80076
You can always use the flag -Wmisleading-indentation. I'm not sure how well it works, though.