6 ms·

braces won't save you from if (something); { do_something(); }

• kgwxd 8y ago
  A basic linter would save you from both problems, assuming they first remove the offending code-style rule.
  • potiuper 8y ago
    A basic linter does not resolve the semantic question. The linter could be satisfied by changing the code syntax given the rule to always include curly brackets after an if to: if (something) {}; { do_something(); } But, the question is the empty bracket correct or should the contents of the subsequent scope be cut into the scope of the if bracket or copied into it or should the if condition be removed altogether? Code styles do not change the intent and always requiring {} after an if is unnecessary for single statements given the intent is correct: if (side_effect()); else { do_something(); } Alternative syntax styles for the same semantics do not clarify the intent of a program.
    • aidenn0 8y ago
      A basic linter will hopefully flag two unrelated statements on the same source line...
    • Sohcahtoa82 8y ago
      > A basic linter does not resolve the semantic question. That's not the job of the linter, that's the job of the engineer. > The linter could be satisfied by changing the code syntax [...] What you're suggesting is the equivalent of turning your car stereo up so that you don't hear the strange noise your car is making. > But, the question is the empty bracket correct or should the contents of the subsequent scope be cut into the scope of the if bracket? That's the job of the engineer to figure out. The linter is only supposed to raise the flag, not come up with the answer.
      • Piskvorrr 8y ago
        This. A hundred times this. Yes, the linter will only save you from basic errors...but indeed, most of the errors are of this type. With a linter, they can be caught even before making it into source control, much less into code review.
    • TheSoftwareGuy 8y ago
      if the curly brackets of an if statement are unnecessary then that should also be an error.
    • pjc50 8y ago
      A decent linter would also warn about the empty block.
• Sohcahtoa82 8y ago
  If I saw that, I'd ask why someone put the code block on the same line as the conditional.
  • ori_b 8y ago
    It also won't save you from if(something); { do_something(); }
    • Sohcahtoa82 8y ago
      A linter wouldn't point out that there's a conditional with no code block? Or a code block being defined unnecessarily?
      • ori_b 8y ago
        Sure, but it'll also catch things like if (a) b; c; So, the brace style really doesn't matter when it comes to tools catching mistakes. If you turn on the warnings and linters, they'll catch all the common bracing errors. If you don't, most of the suggestions here don't really help much.
      • exemplig 8y ago
        > Or a code block being defined unnecessarily? Of course it depends on your configuration, but my organization occasionally uses code blocks to denote things like critical sections in baremetal applications. So you'd have DINT; { // code that should not be interrupted } EINT; I would expect a linter to call out a conditional with no code block, but our workflow is such that we've usually tested things (at least in a manual testing capacity) prior to running any static analysis, so I don't know for sure.
        • Piskvorrr 8y ago
          Yeah. We have spent some time configuring our linters so they match our organization's style - and syntax exists to exclude specific exceptional-but-correct usages from being flagged - but now, if the linter raises any flags, they're almost 100% signal, with only an occasional false alarm*. The rules don't need to be universally applicable :) (The caveat being, of course, that the linter is only a helper tool - "linter doesn't complain" doesn't guarantee correctness, just that "linter complains" is a fairly certain sign of incorrectness)