Is there a reason the kernel style doesn't always require curly braces after "if" statements?
sock->sk = NULL;
https://www.kernel.org/doc/html/v4.10/process/coding-style.h...
Mandatory bracing is a step towards more uniformity, and makes additional statements in a conditional block always safe, and at the cost of just one extra line in the code.
It also makes your commits just a little bit smaller; if you do add more lines to a conditional block that was previously braceless, now you just get the new lines in the diff, instead of new lines + opening brace + closing brace.
Cowboy coding of course scoffs at all this and people have different values when making tradeoffs between readability and concision, but there are good reasons for enforcing mandatory braces.
Would you ditch switch-cases in favor of if-else chains (leaving aside fallthrough/Duff's/etc for a moment) because the latter is uniform with existing constructs? Would you ditch "for (int i = 0; ..." in favor of "int i; for (i = 0; ..."?
No. You're talking about applying style rules for if-else conditionals to statements which aren't if-else, which isn't what I was talking about.
This is why the Linux kernel style guide, OpenBSD style, PSR, etc. all have separate guidelines for switch-case along with guidelines for mandatory bracing in if-else.
> Would you ditch "for (int i = 0; ..." in favor of "int i; for (i = 0; ..."?
There isn't a clear-cut rule about this convention in style guides. That's probably in part because the behavior in your two examples is different: in the first case (in C++), i only exists within the scope of the for loop, whereas in the latter case it will continue to exist outside the scope of the for loop.
Whichever one is appropriate would probably depend on context that's outside the scope of a style guide. They're called style guides, after all, not Programming Rules of Law. :-)
https://developers.redhat.com/blog/2016/02/26/gcc-6-wmislead...
I REALLY do not like just calling something correct because it was in the K&R book.
> Also, note that this brace-placement also minimizes the number of empty (or almost empty) lines, without any loss of readability. Thus, as the supply of new-lines on your screen is not a renewable resource (think 25-line terminal screens here), you have more empty lines to put comments on.
Is that really an acceptable justification in the era of cheap 4K displays?
The statement you quoted is simply saying that the author agrees with K&R. Nothing wrong with it.
Keeping line count down help readability. Some people use high resolution with small fonts but that makes my eyes hurt so my terminal has 45 lines when maximized.
in organizational code that will be looked at by dozens of people potentially over decades, no
if (something)
doThis();
andThat();
What omitting curly braces after `if` statements does do is make code ~1% more readable, which can have massive cumulative positive results in security and stability with a multi-million line codebase.
if (something); { do_something(); }
if (something) {}; { do_something(); }
But, the question is the empty bracket correct or should the contents of the subsequent scope be cut into the scope of the if bracket or copied into it or should the if condition be removed altogether? Code styles do not change the intent and always requiring {} after an if is unnecessary for single statements given the intent is correct:
if (side_effect()); else { do_something(); }
Alternative syntax styles for the same semantics do not clarify the intent of a program.
That's not the job of the linter, that's the job of the engineer.
> The linter could be satisfied by changing the code syntax [...]
What you're suggesting is the equivalent of turning your car stereo up so that you don't hear the strange noise your car is making.
> But, the question is the empty bracket correct or should the contents of the subsequent scope be cut into the scope of the if bracket?
That's the job of the engineer to figure out. The linter is only supposed to raise the flag, not come up with the answer.
if(something);
{
do_something();
} if (a)
b;
c;
Of course it depends on your configuration, but my organization occasionally uses code blocks to denote things like critical sections in baremetal applications. So you'd have
DINT;
{
// code that should not be interrupted
}
EINT;
(The caveat being, of course, that the linter is only a helper tool - "linter doesn't complain" doesn't guarantee correctness, just that "linter complains" is a fairly certain sign of incorrectness)