All posts
Published in design patterns

Should a function or method have only one return statement?

Profile image of Atakan Demircioğlu
By Atakan Demircioğlu
Fullstack Developer

Should a function have only one return statement? This week I think about this question in my mind. This post is about my findings and also…

Should a function or method have only one return statement? image 1

The Single Return Law

When I typed into Google, I found an article with this title. The full article link is here.

  • This rule sometimes calls the “Single Exit Point Rule”

Summary of this blog;

  • Sometimes having multiple exit points is a risk and a bad practice. Because it is getting harder to find the source of the error and decreases the readability.
  • In low-level programming languages, having multiple returns can cause memory leak issues because programmers can forget to clean up early return statements. (In the modern world and in many programming languages there is a GC for the cleanup and this is not a problem)
  • If your function or method is long and has multiple returns, you need to split it up into smaller well-named methods. In this case, I recommend researching SRP and SLAP principles.
  • There are cases where a single return is more readable. But it is not a good fit for all things. If you are trying to use a single return, always consider your lines of code and the complexity of your code. Generally, lines of code are not important and all methods need to apply a single design. I just mean if you want to use single return but your program is going complex, no need for that.
  • Having just one return statement or exit point means you need a variable like “result” and you need to mutate it. In functional programming, we don’t like mutable states. Mutating a variable for a return statement is another thing to discuss. Please check Guard Clause.
  • Keeping track of multiple returns is harder than keeping track of one at the end (especially if you’re not used to it), but keeping track of local variables also has a cost. You trade one for the other based on what you prefer.

Bad Advice — Single Exit Point Rules

I found another article about this and this article is a little bit different. The author directly expresses Single Exit Point as bad advice.

There is an example from the article;

Multiple Returns:

public class Example {
  private int value;

  public int multi(int x) {
    if (x == 10) {
      return -value;
    }

    if (x > 0) {
      return value + x;
    }

    return 0;
  }
}

Single Return:

public int oneAssignment(int x) {
    final int retVal;

    if (x == 10) {
      retVal = -value;
    } else if (x > 0) {
      retVal = value + x;
    } else {
      retVal = 0;
    }

    return retVal;
  }

The question in your mind is which is better? Yay, for this example in my opinion multiple returns are better. In multiple returns, we don’t need a local variable and the logic is more clear when I compare it with the single return. But this is just my opinion.

But this is not mean a single return is bad or multiple returns are good. This is always a trade and you need to decide it every time.

From Code Complete

Minimize the number of returns in each routine. It’s harder to understand a routine if, reading it at the bottom, you’re unaware of the possibility that it returned somewhere above.

Use a return when it enhances readability. In certain routines, once you know the answer, you want to return it to the calling routine immediately. If the routine is defined in such a way that it doesn’t require any cleanup, not returning immediately means that you have to write more code.

Martin Fowler and Kent Beck express things nicely in “Refactoring: Improving the Design of Existing Code”

“. . . one exit point is really not a useful rule. Clarity is the key principle: If the method is clearer with one exit point, use one exit point; otherwise don’t”

There is nothing wrong with single exit functions, but only write them when it makes sense to do so.

Summary

  • Clarity is the key principle: If the method is clearer with one exit point, use one exit point; otherwise don’t.
  • Fewer returns mean less complexity. Linear code is generally simpler to understand.
  • The single exit point gives an excellent place to assert your post-conditions.
  • Having a single exit point does provide an advantage in debugging
  • If trying to simplify a function to a single return causes complexity, then that’s an incentive to refactor to smaller, more general, easier-to-understand functions.
  • Keeping track of local variables also has a cost, you need to consider that.

References