llvm dev - Jul 2020 - Codifying our Brace rules-

Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org> writes:
> For those who don’t like it, is the currently documented policy broken
> enough to be important to changing?
I believe it is, simply for safety reasons.  Adding a statement to a
single-statement block can introduce bugs.  Mandating braces everywhere
prevents that.
> I assume you wouldn’t recommend a massive rewrite of the codebase, so
> we’re going to be with this for quite some time.
Sure, that's unavoidable.  But as code changes we can add braces where
they're missing and reviews should catch cases where we forget.

                  -David

Hi,

For safety and security, I would probably recommend the rules as per Misra C++
The Misra C++ standard not only explains the rules, but also the
safety and security related reason they are the way they are.

Kind Regards

James


On Mon, 29 Jun 2020 at 22:18, David Greene via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org> writes:
>
> > For those who don’t like it, is the currently documented policy broken
> > enough to be important to changing?
>
> I believe it is, simply for safety reasons.  Adding a statement to a
> single-statement block can introduce bugs.  Mandating braces everywhere
> prevents that.
>
> > I assume you wouldn’t recommend a massive rewrite of the codebase, so
> > we’re going to be with this for quite some time.
>
> Sure, that's unavoidable.  But as code changes we can add braces where
> they're missing and reviews should catch cases where we forget.
>
>                   -David
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

> On Jun 29, 2020, at 8:05 AM, David Greene <david.greene at hpe.com>
wrote:
> 
> Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org> writes:
> 
>> For those who don’t like it, is the currently documented policy broken
>> enough to be important to changing?
> 
> I believe it is, simply for safety reasons.  Adding a statement to a
> single-statement block can introduce bugs.  Mandating braces everywhere
> prevents that.
Sure, I get that.  For background, the Swift language (which I was highly
involved in) mandates braces - I’m just saying that I'm aware of the
benefits and tradeoffs here.  In addition to the “safety” advantages, there are
balancing cognitive disadvantages to requiring braces (less code fits on one
screen, etc).  These are all well understood effects.

That said, this is not a new project, and many of the benefits fall below the
line of being “worth it” given a large and established codebase.  I don’t see a
strong reason to change the policy here, though I think we should give more
guidance and clarify the wording!

-Chris

At the very least, I accept clarifying the wording to make it clear where
braces should/shouldn't be used. I personally would still prefer a general
"always add braces in new code" rule, given that I literally just ran
into
another case where a code change I made locally caused test failures
because I'd forgotten to add the braces on a previously single-line if,
although in this case, it should have had braces already, since it had a
comment between the if and statement within the if. clang-formatting would
have pointed out the error, had I run it, but I hadn't done so. Total cost
to me was 2-3 minutes trying to figure out what was wrong. A rule of
"always braces" would have meant those 2-3 minutes could have been
spent on
other things.

On Tue, 30 Jun 2020 at 20:59, Chris Lattner via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
>
> > On Jun 29, 2020, at 8:05 AM, David Greene <david.greene at
hpe.com> wrote:
> >
> > Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org> writes:
> >
> >> For those who don’t like it, is the currently documented policy
broken
> >> enough to be important to changing?
> >
> > I believe it is, simply for safety reasons.  Adding a statement to a
> > single-statement block can introduce bugs.  Mandating braces
everywhere
> > prevents that.
>
> Sure, I get that.  For background, the Swift language (which I was highly
> involved in) mandates braces - I’m just saying that I'm aware of the
> benefits and tradeoffs here.  In addition to the “safety” advantages, there
> are balancing cognitive disadvantages to requiring braces (less code fits
> on one screen, etc).  These are all well understood effects.
>
> That said, this is not a new project, and many of the benefits fall below
> the line of being “worth it” given a large and established codebase.  I
> don’t see a strong reason to change the policy here, though I think we
> should give more guidance and clarify the wording!
>
> -Chris
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200701/e8016ad4/attachment.html>