On: Avoid Else, Return Early (2013)

[Pxtl]

I find a compromise is best.

First, do the simple checks "Oh, this function returns an empty set if one of its parameters is null? Do that".

Then go into the main method body. In the main method body, I want to see elses on ifs. I'm okay with putting a return in each branch of the if/else, but what I find bad is when the main body is

```

  if(foo)
  {
     doLotsOfStufff();
     return myResult;
  }
  return bar;

```

That pattern I can't stand. That's as confusing as switch-block fallthrough.

For those cases, I prefer to see an else. If you must fall through to a final return while you've had a zillion other returns in your branching logic, then that deserves a comment at least explaining that this is the final fallthrough return.

Like

```

  if(foo)
  {
     doLotsOfStufff();
     if(somePositiveCase)
     {
        return myResult;
     }
     if (someOtherNeutralCase)
     {
        doSomePreparatoryThing();
        if (heyMoreChecks)
        {
           return positiveResult();
        }
     }
  }
  // this comment here is super important where we 
  // explain that we couldn't do any positive thing 
  // so this is a failure state.
  
  return barFail;

```

[guitarbill → Pxtl]

So how does the final example even look with else's? I'm not sure what argument you're trying to make with such an awful control flow in the first place?

I also disagree with needing a comment, which is why I think not having an else in the first example is great. Having a return statement at the end of a function is obvious, and then all you have to do is scan upwards to find other return tokens. Especially because the final return need not be an error state.