Re: style change: explicitly permit braces for single statements
At Sun, 12 Jul 2020 10:01:36 +1000, Luke Mewburn wrote: Subject: style change: explicitly permit braces for single statements > > I propose that the NetBSD C style guide in to /usr/share/misc/style > is reworded to more explicitly permit braces around single statements, > instead of the current discourgement. > > 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 Well, if you s/permit/require/g, I strongly concur (with possibly one tiny exception allowed in rare cases -- when there's no newline). Personally I don't think there's any good excuse for not always putting braces around all single-statement blocks. The only bad execuse is that the language doesn't strictly require them. People are lazy, I get that (I am too), but in my opinion C is just not really safe without them. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms pgplEU3KR6NQt.pgp Description: OpenPGP Digital Signature
Re: style change: explicitly permit braces for single statements
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 wrote: > Date:Sun, 12 Jul 2020 13:01:59 +1000 > From:Luke Mewburn > 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 > >
Re: style change: explicitly permit braces for single statements
Date:Sun, 12 Jul 2020 13:01:59 +1000 From:Luke Mewburn 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