3 ms·

The only problem with this is if/when someone comes along and doesn't notice the missing braces and does if (condition) Foo(x) Bar(x) Expecting

The only problem with this is if/when someone comes along and doesn't notice the missing braces and does if (condition) Foo(x) Bar(x) Expecting Bar(x) to be part of the conditional. This can and does happen.

JoeAltmaier 11y ago
I hear folks say that, but don't encounter it in the wild. Maybe once in 20 years so far. That construct, reading it just now, just screams out at me "Indentation error!" Anyway it nicely illustrates the need to get braces out of there altogether. The programmers' intent is obvious; let the IDE 'make it so' by emitting braces in the generated code.
- csixty4 11y ago
  > I hear folks say that, but don't encounter it in the wild. Maybe once in 20 years so far. It was the cause of the "goto fail" SSL bug that affected both of Apple's operating systems last year: https://nakedsecurity.sophos.com/2014/02/24/anatomy-of-a-goto-fail-apples-ssl-bug-explained-plus-an-unofficial-patch/ https://nakedsecurity.sophos.com/2014/02/24/anatomy-of-a-got... So I'd say it's rare, but it happens. And when it happens, the effects can be pretty big.
- jotux 11y ago
  I've never seen (in code I've worked on) if (condition) Foo(x); Bar(x); But I have seen if(condition1) if(condition2) if(condition3 && condition4) Foo(); This upset the old ARM compiler I was working on and it decided to skip some of the conditions. I fixed the bug, related to this code, by adding braces: if(condition1) { if(condition2) { if(condition3 && condition4) { Foo(); } } } So this is why I always put braces to define scope. Although, in general, both of these types of bugs are uncommon. Honestly, the more pervasive problem that comes up is the eventual addition of new code adds noise to diffs. Like if I have a condition with a single statement if (condition) Foo(x); And I add something to it, I have to add braces and it pollutes the diff with stuff that isn't really related to what I'm changing. if (condition) { Foo(x); Bar(); }
  - dllthomas 11y ago
    "This upset the old ARM compiler I was working on and it decided to skip some of the conditions." Do what you need to work around a known compiler bug, of course, but that is definitively a compiler bug. The meaning is unambiguous and consistent in the C standard and every implementation I've encountered. I'm not comfortable with the assertion that changing your coding style here makes you less susceptible to compiler bugs in general.
- barrkel 11y ago
  I agree with you - I can count the number of times I've seen it in my life on one hand - but ever since the Apple bug, lots of people use it as a club to hit people over the head with, to enforce braces everywhere. There seems to be a logical error to me. An indentation mistake - something that can be caught trivially by a linter - is not significantly different by nature than any other single-character mistake, like an incorrect constant or misspelled identifier (harder to find with a linter). But because it was at the root of a specific flaw, it's become larger than life.

JoeAltmaier 11y ago

I hear folks say that, but don't encounter it in the wild. Maybe once in 20 years so far. That construct, reading it just now, just screams out at me "Indentation error!" Anyway it nicely illustrates the need to get braces out of there altogether. The programmers' intent is obvious; let the IDE 'make it so' by emitting braces in the generated code.

csixty4 11y ago
> I hear folks say that, but don't encounter it in the wild. Maybe once in 20 years so far. It was the cause of the "goto fail" SSL bug that affected both of Apple's operating systems last year: https://nakedsecurity.sophos.com/2014/02/24/anatomy-of-a-goto-fail-apples-ssl-bug-explained-plus-an-unofficial-patch/ https://nakedsecurity.sophos.com/2014/02/24/anatomy-of-a-got... So I'd say it's rare, but it happens. And when it happens, the effects can be pretty big.
jotux 11y ago
I've never seen (in code I've worked on) if (condition) Foo(x); Bar(x); But I have seen if(condition1) if(condition2) if(condition3 && condition4) Foo(); This upset the old ARM compiler I was working on and it decided to skip some of the conditions. I fixed the bug, related to this code, by adding braces: if(condition1) { if(condition2) { if(condition3 && condition4) { Foo(); } } } So this is why I always put braces to define scope. Although, in general, both of these types of bugs are uncommon. Honestly, the more pervasive problem that comes up is the eventual addition of new code adds noise to diffs. Like if I have a condition with a single statement if (condition) Foo(x); And I add something to it, I have to add braces and it pollutes the diff with stuff that isn't really related to what I'm changing. if (condition) { Foo(x); Bar(); }
- dllthomas 11y ago
  "This upset the old ARM compiler I was working on and it decided to skip some of the conditions." Do what you need to work around a known compiler bug, of course, but that is definitively a compiler bug. The meaning is unambiguous and consistent in the C standard and every implementation I've encountered. I'm not comfortable with the assertion that changing your coding style here makes you less susceptible to compiler bugs in general.
barrkel 11y ago
I agree with you - I can count the number of times I've seen it in my life on one hand - but ever since the Apple bug, lots of people use it as a club to hit people over the head with, to enforce braces everywhere. There seems to be a logical error to me. An indentation mistake - something that can be caught trivially by a linter - is not significantly different by nature than any other single-character mistake, like an incorrect constant or misspelled identifier (harder to find with a linter). But because it was at the root of a specific flaw, it's become larger than life.