Avoid Else, Return Early (2013)

Post by RobertRoberts » Mon, Mar 26, 2018, 5:15 PM UTC

MaulingMonkey wrote: post #353

RobertRoberts wrote: post #288

Earlier quoted context omitted.

Not being a pest here, but how often are you comparing more than 2 functions at a time? I can't say that I have ever dealt with code in over 20 years where I had to deal with more than 2 functions at once. Maybe I am mentally disabled, but I can only focus on one logical task at a time. Can other programmers multi-task their coding?

Refactoring might have you adding a parameter to a function, and then feeding that additional parameter to the function at it's call sites. Even when you only have one call site and thus are in the "2 functions" case - these two functions are often separated by multiple "irrelevant" functions. The less scrolling, tab management, and other context switching I have to do to look at those "2" functions, the easier it is…

Post by masklinn » Mon, Mar 26, 2018, 5:18 PM UTC

SideburnsOfDoom wrote: post #49

masklinn wrote: post #33

Earlier quoted context omitted.

Also functional languages with function guards e.g. while Erlang/Elixir does not have a return statement (and thus early return) you can write handle(Err, Results) when Err /= undefined -> handle_error(Err); handle(_, Results) -> % etc… . though errors would generally be reified as the ad-hoc union of two tuples and would look more like this: handle({error, Info}) -> handle_error(Info); handle({ok, Results}) -> % han…

The functional style that you show certainly has multiple points where a value is returned, so you could call it "early return"; even if as a syntactic shorthand the keyword "return" is omitted. This is common across a lot of functional languages.

    function(err, results) {
      if (!err) {
         // handle results
      } else {
         return handleError(err)
      }
    }

Post by maxxxxx » Mon, Mar 26, 2018, 5:20 PM UTC

augustk wrote: post #361

maxxxxx wrote: post #209

Earlier quoted context omitted.

I am on board with returning at the beginning while checking arguments. But I hate it when code returns somewhere in the middle for some reason. I have spent countless hours debugging a problem with unexpected behavior only to find a return statement in the middle of a huge block to code.

That's because the return statement is a kind of goto statement. Goto-like statements reduce the value of structured programming. In a pure structured program, each statement sequence is either completely executed or not executed. There are also pure structured languages, like Oberon, which doesn't allow impurely structured programs.

Post by gwbas1c » Mon, Mar 26, 2018, 5:21 PM UTC

toomanybeersies wrote: post #48

Cthulhu_ wrote: post #6

A 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/

I was more or less required to use guard clauses by my manager at my previous job. I used to hate being forced to use them, just because as a recent computer science graduate I was happy with nested conditionals everywhere. But guard clauses make life so much easier, I eventually discovered. They make testing your code a lot easier, and also make reasoning about the code and reading it so much easier. Ruby makes writ…

Post by timoxley » Mon, Mar 26, 2018, 5:22 PM UTC

arghwhat wrote: post #92

Waterluvian wrote: post #51

Earlier quoted context omitted.

JavaScript has the guard operator. It can really clean up your control flow when you know it's a guard operator and not just logical AND.

Logical AND in JavaScript can be used as a guard, by why in the world would you think of it as anything other than a logical AND? If you start thinking it is a "guard operator", I would think that going down the wrong path, which might promote misunderstanding of the behavior.