Avoid Else, Return Early (2013)
blog.timoxley.com
Avoid Else, Return Early (2013)
1–10 of 601 posts
Re: Avoid Else, Return Early (2013)
#2I agree with much of the article (return early, errors management at the top, etc.). But won't returning a "wrong" value for the sake of one less line worsens the readability of the code?
When I saw that, I imagined myself spending 10 minutes trying to understand why he does that. But maybe I'm not familiar with a JS best practice here.
Re: Avoid Else, Return Early (2013)
#3"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.
Re: Avoid Else, Return Early (2013)
#4Seems to me that there is quite a bit of commentary on this subject, and you can find it by searching for its typical solution: guard clauses[1].
Re: Avoid Else, Return Early (2013)
#5I would agree. Putting "early out" logic at the beginning allows the one who reads the code to lower the cognitive load a bit. Basically "I know I can read the following code safely because the error handling and parameter sanitizing is done". But that only works with mundane operations (error handling, parameters sanitizing). If the operations convey some important semantics, then I prefer to see the guarded code inside an if block...
Re: Avoid Else, Return Early (2013)
#6A more formal name for this approach is / could be Guard Clauses: https://refactoring.com/catalog/replaceNestedConditionalWith.... This pattern has been elevated to a language construct in Swift: https://thatthinginswift.com/guard-statement-swift/
Re: Avoid Else, Return Early (2013)
#7Avoid rules, use your judgment.
Re: Avoid Else, Return Early (2013)
#8"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;
Re: Avoid Else, Return Early (2013)
#9Seems to me that there is quite a bit of commentary on this subject, and you can find it by searching for its typical solution: guard clauses[1]. [1] http://wiki.c2.com/?GuardClause
Yeah, Swift in particular really embraces that pattern.
Re: Avoid Else, Return Early (2013)
#10I agree with much of the article (return early, errors management at the top, etc.). But won't returning a "wrong" value for the sake of one less line worsens the readability of the code? When I saw that, I imagined myself spending 10 minutes trying to understand why he does that. But maybe I'm not familiar with a JS best practice here.
returning a wrong result is definitely wrong. It conveys some unexpected meaning and side effects...