[llvm-dev] Codifying our Brace rules-

[Fangrui Song via llvm-dev]

On 2020-06-24, David Chisnall via llvm-dev 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();
>
>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

First, there is a merge conflict:

--- i/a.c
+++ w/a.c
@@@ -1,2 -1,5 +1,8 @@@
  -if (x) {
  +if (x)
      something();
++<<<<<<< HEAD
++=======
+    somethingElse();
+    onemorething();
+ }
++>>>>>>> 78750e9... onemore


Second, both GCC>=6 and clang (https://reviews.llvm.org/D70638 ) -Wall enable
-Wmisleading-indentation to catch the issue.