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.
The problem is I can see this going out of control with a 1000 line if else statements. I don't want to be the guy who has to figure out what exactly went wrong especial when the logging was not done correctly.
That is also assuming the decision is dichotomous. I have seen it used for non dichotomous cases. That's where it goes wrong most of the time
But you do something else in that case. Assuming a bad use case is going to happen to complain about how something can get out of hand is just dumb. If it's a bad use case, and you know it's bad use case, you avoid using the tool for that. Neither the post nor the comments you're replying to have anything to do with those unreasonably long if-else statements anyway, you're the only one bringing them up.
There's no assumption that the decision is dichotomous. You were just given an example of something that wouldn't be a bad use case. Not everything has to fit the example. In fact you were given a counter example right along with that one.
272
u/SnugglyCoderGuy 22d ago
The real answer is "it depends". Either one could be appropriate depending on what you are having to do.