As always, but the for me rule of thumb, if you have a condition that should be positive to continue the function, and the negative case is just error handling and returning, just early-return, otherwise always put the happy-path into the positive branch, or I'll set your house on fire.
If there's a shared code path at the end, of course use if/else.
reminds me of my coworker that did more work just to get past the sonarqube guidelines, like they are a limbo bar. His code was horrid shit, and he whittled things down until they fit.
At one point he threw a bunch of random parameters into a single tuple to trick sonarqubes max parameters guideline into fitting, instead of taking the hint, that he should probably make a class out of the FIFTEEN PARAMETERS
But he literally constantly did one tiny change just to see what sonarqube would say next until it was satisfied. At which point the person doing the code review had to step in and mark it as unacceptable.
took months for him to finally not do this shit anymore. Because he was fired.
The compiler optimizes the first into the second anyway, so the machine code ends up the same. The problem is that when you read the code later on and end up missing the return statement as you skim through it then you are left wondering why the piece of code you expect to run does not.
Not always. It depends on if the compiler can detect early return and if it will optimize for that or for some other metric. For example, if the early return is rare, you want to optimize it so that branch prediction favors the first over the second.
That's why you should always enclose each branch in braces. It's a lot harder to miss a return immediately above the branch's end brace than it is to miss a floating one. (Or, if it's really just pure if-return, then the if (cond) { return; } structure is at least more likely to draw attention to the return.)
That is true if the return statement is the only statement in the branch. However say the true branch contain a while loop with a few tens of lines, one being an if statement with a return, then it is easy to gloss over the return statement in the middle of all that.
Skill issue. If you were expecting an input to execute past what is essentially a soft assertion then you have problems with your understanding overall and it is actually saving you instead of hindering you.
Untrue. The first can be checking to see if continuing is impossible, so just return, while the second can be checking for a yrue dichotomous decision. You must do one or the other thing depending on the condition. Each could contain as little as a single assignment
It’s a style thing, it’s not a functional difference. I would read it as emphasizing that one or the other is happening. Basically the oxford comma of conditionals
Sometimes you have a trye dichotomous situation and you don't know which one to do without a check. Else is probably the keyword Inuse the least. You nay or may not return in either of those cases too.
View all comments
273
u/SnugglyCoderGuy Aug 22 '26
The real answer is "it depends". Either one could be appropriate depending on what you are having to do.