Java Basics
Commentary: Return statements and the single exit fantasy
Structured programming purists. A controversial "rule" used by strict structured programmers is that every method should have only one return statement at the end. Their reasoning is that it is easier to understand control flow when you know exactly where the method returns (the end).
The single return issue is often called the single exit issue, and it
also applies to use of the continue
and break statements in loops, which are forbidden by the purists,
but allowed by the simplifiers.
Simplifiers. Altho a single exit is appealing, code can become quite convoluted with setting and testing additional extra boolean variables which are needed to implement a single exit style. Most programmers probably support the idea that simple readable code in more important than following any arbitrary rule. If coding to achieve a single return means complicating the code, then it's a mistake.
Exercise: Change this to single-return style
It's fairly easy to rewrite this to use only a single return; try it. And don't use a break statement in the loop because this also violates the single-exit style.
1 2 3 4 5 6 7 8 9 10 11 12 |
//======================================================= primeFactor // Return a factor of n, or 0 if n is prime. // Uses simple algorithm of dividing by all numbers up to n. // Could improve efficiency many ways. public static int primeFactor(int n) { for (int divisor = 2; divisor < n; divisor++) { if ((n % divisor) == 0) { return divisor; // Divisible implies not prime! } } return 0; // Must be prime if nothing was able to divide it. } |
Variations on max()
showing several possible return strategies
Problem: Write a method to compute the maximum of two double values. These alternate implementations show that even this simple problem offers several alternatives on where to return.
Version 1 - Return immediately
This is a straightforward example of returning the value as soon as it's known.
public static double max(double a, double b) { if (a > b) { return a; } else { return b; } }
Version 2 - Single return
The orthodox philosophy of Structured Programming is that every method should have only one return at the end. To implement this, use a variable to hold the max value and return it at the end.
public static double max(double a, double b) {
double result; // Stores the maximum value until the return.
if (a > b) {
result = a;
} else {
result = b;
}
return result;
}
This method is clear in either style, but the rigid application of the one-return rule can make some methods very convoluted. The overriding principle that most programmers use is that program flow should be as clear as possible.
Version 3 - No need for else when the true part returns.
public static double max(double a, double b) { if (a > b) { return a; } return b; // Only executed if comparison was false. }
Version 4 - Typical hacker obfuscation
The hard-to-read ?:
operator is a favorite
of programmers who want to impress others. It does result in
shorter source code (but not more efficient execution).
Most people don't find this more readable.
public static double max(double a, double b) {
return a>b?a:b;
}
It could be made more readable with ()s and spacing.
return (a > b) ? a : b;
Library. Of course you should use the predefined methods (Math.max()
) rather than writing your own!
Uncaught exceptions moot the issue
The third way to exit a method.
The return
statement and the end of the
method are not the only ways to return from a method.
Uncaught exceptions are the other way to exit a method.
- A
throw
statement exits the method. - Calling any method which throws exceptions many be a point at which the method is exited. If it throws unchecked exceptions, it may not be easy to determine that they are thrown.
- Any statement which could cause an exception is another potential exit point.
Editor support for showing method exit points
Some editors may highlight method exit points. This is perhaps a better solution than trying to bend the code to fit a particular rule.
Additional Discussion
- Multiple return statements (http://www.javapractices.com/Topic114.cjp) Argues that multiple returns, altho subject to abuse, can make code clearer, especially in handling exception cases at the beginning.
- Multiple Return Statements (http://onthethought.blogspot.com/2004/12/multiple-return-statements.html) Bruce Eckel argues that multiple return statements can make "cleaner" code. If multiple returns are being used in a bad way, enforcing a rule like this probably won't make the programmer write clear code in any case.
- Code improvement guidelines
(http://jroller.com/comments/fra3k/Weblog/code_improvement_guidelines)
Argues for single return statements on the basis of clarity, which is curiously
the same basis that is used for multiple return statements.
Nice argument for multiple return statements in a response to this blog
entry (in
equals()
).