[potiuper]

braces won't save you from

if (something); { do_something(); }

[kgwxd]

A basic linter would save you from both problems, assuming they first remove the offending code-style rule.

[potiuper]

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.

[Sohcahtoa82]

> 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]

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.

[aidenn0]

A basic linter will hopefully flag two unrelated statements on the same source line...

[pjc50]

A decent linter would also warn about the empty block.

[TheSoftwareGuy]

if the curly brackets of an if statement are unnecessary then that should also be an error.

[Sohcahtoa82]

If I saw that, I'd ask why someone put the code block on the same line as the conditional.

[ori_b]

It also won't save you from

    if(something);
    {
       do_something();
    }

[Sohcahtoa82]

A linter wouldn't point out that there's a conditional with no code block? Or a code block being defined unnecessarily?

[ori_b]

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]

> 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]

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)