A few years ago when I worked at Tesla, we had to have our production code pass a MISRA C linter: https://gimpel.com/
MISRA C requires braces even with a single clause. I'm not going to try to justify MISRA C's rules; but only say that 'programmers in automobile / embedded' world probably find this extra brace practice normal. I have a 4K screen, so a few lines wasted this way... doesn't really bother me anymore. If I were bothered, I'd make the font 1 or 2 points smaller and get more lines. (If any of us is still using an 80 x 24 terminal -- here's a nickel: https://dilbert.com/strip/1995-06-24 ) On Sun, Jul 12, 2020 at 1:50 AM Robert Elz <k...@munnari.oz.au> wrote: > Date: Sun, 12 Jul 2020 13:01:59 +1000 > From: Luke Mewburn <lu...@netbsd.org> > Message-ID: <20200712030159.gh12...@mewburn.net> > > > | | IMHO, permitting braces to be consistently used: > | | - Adds to clarity of intent. > | | - Aids code review. > | | - Avoids gotofail: > https://en.wikipedia.org/wiki/Unreachable_code#goto_fail_bug > > > Permitting the braces is probably no big deal, but does none of > that. Actually using the extra braces might, but unless you change > "permitting" to "requiring", that's unlikely to happen a lot. > > I simply cannot see myself changing > > if (p == NULL) > return NULL; > > into > > if (p == NULL) { > return NULL; > } > > Aside from anything else, the closing brace occupies an extra > line (and often two, as those are often followed by blank lines) > which means two less lines of context I get to see in my window > (however big the window is - enlarging it still means 2 less lines > of context than would be possible) - and that's for each time this > is done. > > But as long as they're just permitted, and not required, then I > don't have a big problem with it - but note that if I'm working > on code written like that, I'm likely to delete non-required > meaningless braces (just as cleaning up trailing whitespace, > fixing tab vs space indentation, and wrapping long lines, etc). > > kre > >