[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.