"Do not unnecessarily use braces where a single statement will do."
https://www.kernel.org/doc/html/v4.10/process/coding-style.h...
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...
in organizational code that will be looked at by dozens of people potentially over decades, no
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.