[llvm-dev] Codifying our Brace rules-

Mehdi AMINI via llvm-dev llvm-dev at lists.llvm.org
Wed Jun 24 09:08:01 PDT 2020


On Wed, Jun 24, 2020 at 3:02 AM David Chisnall via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On 23/06/2020 16:51, Adrian McCarthy via llvm-dev wrote:
> > Personally, I favor "always use braces" because it helps readability for
> > me.  The compiler may be good at flagging misleading indentation, but my
> > visual processing system is terrible at it, especially since we use a
> > measly two spaces for indentation.  And we grant indentation exceptions
> > for--among other things--case labels in switches.
>
> I remember fixing one bug in LLVM that was caused by not having braces
> around an if statement and a modification that didn't notice this.  I
> have fixed other bugs in a downstream fork where upstream has done this:
>
> if (x) {
>    something();
>    somethingElse();
> }
>
> We've changed it to:
>
> if (x) {
>    something();
>    somethingElse();
>    ohAndOneMoreThing();
> }
>
> And then upstream has changed it to
>
> if (x)
>    something();
>
> And, after merge, our code has been:
>
> if (x)
>    something();
>    ohAndOneMoreThing();
>

To be clear this was a merge-conflict that was manually resolved this way
right? I don't see git auto-merging this diff.


> In contrast, I have *never*, in any project, had to fix a bug that was
> caused by someone inserting redundant braces (or extra brackets) and
> someone else failing to understand the code.
>
> As such, I am strongly in favour of requiring extra braces.  Static
> analysers will now often catch the bugs that they prevent but it's
> better to make it harder to introduce bugs in the first place than to
> depend on tooling to find them later.
>
> David
>
> _______________________________________________
> 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/20200624/1dc80a5a/attachment.html>


More information about the llvm-dev mailing list