When not to use early return?

Question

Nesting is unavoidable, however in most cases returning early is a more viable option.
Consider the following snippet:

MyRoutine(argument)
{
    if (0 == argument) {
         SubRoutine(argument);
    } else if (1 == argument) {
         SubRoutineForSomething(argument);
    } else {
         SubRoutineForMe(argument);
    }

    return this;
}

I find myself constantly refactoring that to

MyRoutine(argument)
{
    if (0 == argument) {
         SubRoutine(argument);

         return this;
    }

    if (1 == argument) {
         SubRoutineForSomething(argument);

         return 1;
    }

    SubRoutineForMe(argument);

    return this;
}

Only exception is to keep things DRY, so instead of

MyRoutine(argument)
{
    if (0 == argument) {
         SubRoutine(argument);
         AnotherAction();

         return this;
    }

    if (1 == argument) {
         SubRoutineForSomething(argument);
         AnotherAction();

         return 1;
    }

    SubRoutineForMe(argument);
    AnotherAction();

    return this;
}

I'd rather use

MyRoutine(argument)
{
    if (0 == argument) {
         SubRoutine(argument);
    } else if (1 == argument) {
         SubRoutineForSomething(argument);
    } else {
         SubRoutineForMe(argument);
    }

    AnotherAction();

    return this;
}

Are there any major disadvantages to exiting early? I'm moving from serverside work towards game development (Javascript and C-like languages). Are there any pitfalls I should watch out for/benefits I'm missing (branch prediction)?

I hope this is different than this question.

If you are concerned about a possible duplicate, do not hope it is different: evaluate whether the answers on the other question could answer yours. If so, you found your answer. If you feel your question is substantially different, explain why. — , Jun 14 '15 at 01:58

score 4 · Answer 1 · answered Jun 13 '15 at 21:53

This may be a little bit opinionated, but I recommend using "early return" when it makes the code simpler to read, and especially when it reduces the nesting level. However, IMHO the refactored version of your first example fulfills none of those two conditions (in fact, I think in your example the readability is a little bit decreased), so that is exactly an example where it is not very beneficial to use "early return".

score 1 · Answer 2 · answered Jun 13 '15 at 22:05

Your refactoring doesn't make much sense. I don't see any scenario where you would return two different types, i.e. either this or an integer number, so return this is almost certainly going to go at the bottom of the if tree, and the original code is better.

In addition, if (0 == argument) is pretty much not used anymore, unless you're using a C compiler that's not smart enough to warn you when you're trying to make an unintended assignment in an if condition.

Depending on what you're actually trying to accomplish, you might be better off with something like this:

MyType MyRoutine(argument)
{
    switch(argument)
    {
        case 0: return someFunctionReturningAnInstanceOfMyType();
        case 1: return someOtherFunctionReturningAnInstanceOfMyType();
    }
    return default(myType);
}

which is clean, simple, and always returns early, except in the default case.

score 1 · Answer 3 · answered Jun 13 '15 at 23:44

Waiting to return until the very end of the function is very useful in languages where you must release resources before you return, because since you only have one exit point, you can be sure you're cleaning up before you leave.

In languages that have automatic garbage collection, returning early doesn't have that disadvantage. In fact, Rubocop, a static code analyzer for Ruby, encourages you to refactor methods to return early when you are checking parameters. That's called a guard clause. In my own experience, it really helps clear up nasty if/else chains in certain situations.

You say you may be programming in C-type languages as well as JavaScript. I return early in JavaScript all the time for these reasons. However you'd be better off avoiding this in C-type languages, otherwise you'd duplicate (or forget) cleanup code.

When not to use early return?

3 Answers3

Linked

Related