I usually prefer explicit if...else blocks even when all or some of them return, because it's always good to see the big picture with blocks that are executed only on certain condition. In other words, see the code tree almost literally.
Avoid Else, Return Early (2013)
11–20 of 601 posts
Re: Avoid Else, Return Early (2013)
#12Sort of agree, but I don't think
if (err) {
handleError(err)
return
}
if (err) return handleError(err)
Re: Avoid Else, Return Early (2013)
#13If you have a complicated function, and several exit points where you want to bail out, they why not just put a "label: bail" and goto it?
GOTO has a bad rap IMO. There's a place for it, and the author should probably be using it.
Re: Avoid Else, Return Early (2013)
#14Avoid rules, use your judgment.
That's awful advice. Obviously _someone_ has to use their judgement to _create_ the rules. But if you have a large codebase that lots of people are interacting with, letting everyone "use their judgement" is going to create an unreadable mess of code, because you're going to have different patterns and approaches all over the place. It would be like writing a book and one paragraph is in English, the next in Spanish, the third in French, then the fourth goes back to Spanish, and on and on.
Re: Avoid Else, Return Early (2013)
#15thanks for raising that up, it's always good to doubt anything obvious, however, it looks like it'll continue writing if-else complete code :)
Re: Avoid Else, Return Early (2013)
#16"removing a whole line and more braces" - this is really fighting the wrong enemy. Code should be written in a way it is more readable, not shorter.
"Code should be written in a way it is more readable, not shorter."
Personally I think sometimes shorter code, that gets rid of unnecessary bureaucracy, is more readable. For example, C++ recently (in the past decade...) gained range based iteration.
Previously:
for(containe_type::iterator i = my_container.begin(); i != my_container.end(); i++){ do_stuff(i); }
Now:
for(auto& i : my_container) { do_stuff(i); }
This is really context sensitive. Some code benefits from verbosity while other don't.
Re: Avoid Else, Return Early (2013)
#17I do this all the time in Ruby, Python, JavaScript because the code is so easier to read. Error management tends to stick to the beginning of functions/methods and the main algorithm doesn't have to be indented.
With Ruby it's even cleaner because of the postfix conditionals.
def something()
return value2 if error1
return value2 if error2
do_something
end
Re: Avoid Else, Return Early (2013)
#18"removing a whole line and more braces" - this is really fighting the wrong enemy. Code should be written in a way it is more readable, not shorter.
Exactly. This led to the famous OSX double goto bug [0] if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail; goto fail; ... other checks ... fail: ... buffer frees (cleanups) ... return err; [0] https://www.dwheeler.com/essays/apple-goto-fail.html
The goto fail snippet doesn't conform to the "one logical statement per line" guideline in the article though, so the author would advise against this style too.
Re: Avoid Else, Return Early (2013)
#19I switched to using this style in the last few years, but it only works well where the code is reasonably good quality otherwise, in particular with short methods and classes. If you're dealing with legacy code with massive procedural style methods having return statements scattered around makes things even more confusing.
Re: Avoid Else, Return Early (2013)
#20"removing a whole line and more braces" - this is really fighting the wrong enemy. Code should be written in a way it is more readable, not shorter.
Exactly. This led to the famous OSX double goto bug [0] if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail; goto fail; ... other checks ... fail: ... buffer frees (cleanups) ... return err; [0] https://www.dwheeler.com/essays/apple-goto-fail.html
`goto` wouldn't be used in a return early philosophy.