Re: style change: explicitly permit braces for single statements

[Michael Cheponis <michael.cheponis%gmail.com@localhost>]

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 <kre%munnari.oz.au@localhost> wrote:

>     Date:        Sun, 12 Jul 2020 13:01:59 +1000
>     From:        Luke Mewburn <lukem%NetBSD.org@localhost>
>     Message-ID:  <20200712030159.GH12055%mewburn.net@localhost>
>
>
>   |   | 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
>
>