Of course you can, it's a tiny, isolated example consisting of 5 or so tokens. That's not how real programs look like so you cannot take the example so literally.
The second form is superior for at least three reasons:
1. Enables a property corollary to the happy path rule, which is that every return statement of a function is at the beginning of a line. This property is crucially important for readability, it makes it reliably possible to determine every exit point of a function by merely scanning the left hand vertical slice of it as opposed to needing our eyes to jump around erratically searching for arbitrarily placed returns.
2. Uniformity: mixing different if statement styles in a single codebase interferes with our ability to match visual patterns. Since we can no longer rely on every if statement looking the same, we cannot quickly skim over code anymore.
3. Refactorability: it's easier to add another line of code to the if statement if there's no need to also add brackets.
Bugs. Subtle horrible bugs that can take forever to find. Not having the braces makes it so easy to accidentally break in later changes or refactoring. Sure on its own it's super obvious, but next to other changes or refactoring it is really easy to miss that suddenly logic falls out of the condition or doesn't make sense anymore.
I don't remember the details but I've had some typo in a one-line-if-condition once and it took me days to find it. Might have been an accidental semicolon in C. A linter enforced the braces and line-breaks and made it obvious.
Anyways, running a linter also helps because all anger or frustration can be directed towards the machine.
> Not having the braces makes it so easy to accidentally break in later changes or refactoring.
Did you mean “not having a linter”? Because once you have a linter you no longer need the braces because the autoformatting will always fix the indentation.
Perfectly valid and people do it. But then later on someone might put a debug statement above the return to check something. Or add some other logic.
if (foo)
doSomething();
return;
And suddenly the logic is broken and the return falls out of the if-condition. It looks fairly contrived with an example like this but easy to do when code is a bit more complicated or people are tired or rushed. It's a good habit to always enforce braces for if-conditions as it defeats that whole category of mistakes. Fairly innocent but can be so hard to find because of that.
A linter would enforce having braces and solve the issue. And for codebases without a linter it is a good habit to just go with the braces.
The trouble is with those rush code out without really looking what they are doing. They make those mistakes, very easily, indeed.
No style could save us from those devils!
People should take the necessary attention to make quality work (and use proper techniques, where proper does not entail style or other visuals or appearances, not at all. That's for superficious persons). This is true for any part of life not just coding.
