Bad Advice - Single Exit Point Rules

Some coding standards mandate that all methods should have a single exit point.

Doing so can be damaging, particularly when it is enforced by static analysis.

Details

Single exit point is an idea with a long history dating back to the era of liberally applied gotos and spaghetti code.

In that context, adding constraints on what could happen within a function was helpful. Knowing that there is only one point that a large function can exit from makes it easier to understand.

Many modern functional languages continue to either enforce or encourage single exit points.

So it must be a good idea to add this constraint to Java right?

Lets look what happens when we are told we must only have one exit point:

Single exit with statements

  1. public class Example {
  2.   private int value;
  4.   public int single(int x) {
  5.     int retVal = 0;
  7.     if (x == 10) {
  8.       retVal = -value;
  9.     } else if (x > 0) {
  10.       retVal = value + x;
  11.     }
  13.     return retVal;
  14.   }
  16. }

If we remove the single exit point constraint we get:

Multiple exit

  1. public class Example {
  2.   private int value;
  4.   public int multi(int x) {
  5.     if (x == 10) {
  6.       return -value;
  7.     }
  9.     if (x > 0) {
  10.       return value + x;
  11.     }
  13.     return 0;
  14.   }
  15. }

Which version is better?

There isn’t much in it, but the multiple exit point version is easier to comprehend.

Trying to apply the single exit point constraint resulted in an additional local variable to hold return state. In the multi exit version we can clearly see what is returned when none of the conditions match. In the single exit version it is slightly less clear as the returned value is declared at the start of the method then overwritten.

So does this mean that single exit point methods are bad?

No.

It is possible to write alternate single exit implementations.

  1.   public int oneAssignment(int x) {
  2.     final int retVal;
  4.     if (x == 10) {
  5.       retVal = -value;
  6.     } else if (x > 0) {
  7.       retVal = value + x;
  8.     } else {
  9.       retVal = 0;
  10.     }
  12.     return retVal;
  13.   }

We’ve addressed the issues we identified earlier. We only assign to retVal once and it is clear what is assigned when none of the conditions match.

Is this superior in some way to the multi exit version?

Not really.

We can also write a single exit method using the ? operator:

Single exit with the ? operator

  1.   public int expression(int x) {
  2.     return  x ==  10 ? -value
  3.         : x > 0  ? value + x
  4.         : 0;
  5.   }

We have switched from using a statement (if) to working with expressions (i.e. things that return a value). This allows us to get rid of the additional variable while maintaining a single exit point.

Is this version clearer than the multi-exit version? That is debatable and ultimately a matter of personal taste.

The code using ? is terse and some will find it harder to understand.

The multi-exit version is more verbose but its proponents would argue it is easier to comprehend.

If your personal preference is for the ? operator version, it still does not follow that the single exit point rule is something you should try to universally apply.

The most likely result is that you will push people towards writing code like the earlier bloated version of our method. As Java is a largely statement-based language, you will also encounter logic where the multi-exit version is undeniably clearer.

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.