It’s funny just about the only thing anyone really objected to from my recent post on Minimal Coding Style was multiple return statements.
Let’s start by looking back to where this idea stems from. As best I can tell objections to multiple returns stem from Dijkstra’s 1968 paper “Go To Statement Considered Harmful”. From David Tribble who has written a Retrospective on the letter, from the introduction:
This paper was written at a time when the accepted way of programming was to code iterative loops, if-thens, and other control structures by hand using goto statements. Most programming languages of the time did not support the basic control flow statements that we take for granted today, or only provided very limited forms of them. Dijkstra did not mean that all uses of goto were bad, but rather that superior control structures should exist that, when used properly, would eliminate most of the uses of goto popular at the time. Dijkstra still allowed for the use of goto for more complicated programming control structures.
Here is what I believe about methods:
- Short, Short, Short – at most one screen long – anything more requires the reader to scroll up and down to understand the code.
- Do only one thing – for the ultimate anti example of this: Munger (MacOS 7/8/9) the swiss army knife of memory allocation that did different things depending on the combination of parameters. Note the linked article doesn’t describe a fraction of what Munger did. Be afraid.
- Have descriptive (but not verbose) name.
- Be simple and easy for the maintainer to read – this implies reducing the complexity of the control structures.
Some reasons I dislike the single exit argument:
- If there are cases that aren’t applicable (invalid method arguments, …) I like to exit the method early to avoid additional indentation.
- Without early exits we have to keep track of whether each additional branch was intended to execute.
- Without early exits the ‘result’ might accidentally get changed, meaning the wrong value is returned.
- If more code is added later it might accidentally get run even though its author intended the method to be finished.
- If you need to clean up use a try/finally block since even early returns pass through finally blocks.
- If multiple return statements make a method hard to read then the method is probably too large. In addition most IDE’s will allow you to highlight the control statements in any colour you need to make them visible.
More than a few other people have written on this in recent years: Bruce Eckel, Java Think (Taylor Gauthier), Java Basics, Peter Ritchie.
Do the person reading your code in the future a favour. Use early return statements to minimize the complexity in your code.
Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.
It’s funny – once upon a time I was a die-hard advocate of “one entry point, one exit point” for a method or function. My main argument for this was that it greatly simplified debugging. Then, I found out about automated testing in general and TDD in particular and I’ve switched camps to be an advocate of “early returns”!
I would say, though, that early returns don’t necessarily make code less complex. If the code isn’t well-factored to begin with, they can actually make the code less readable. I think that maybe a better way to put this is that if the code has good automated tests and is well-factored (according to Beck’s priority list), then early returns can make it even more readable than nested control structures. There’s a synergy there that needs to be brought to the surface.
Dave…
I like multiple return statements not just for cutting down on if..then indentation but to show the reader where the meaty problems like. That is, I exit early in simple cases to show the reader that these problems were easily taken care of. If you continue on in the method means something harder had to be done.
Some of your points could be reversed. You say “If more code is added later it might accidentally get run even though its author intended the method to be finished.” The reverse is more likely to be true. If a developer goes back to the method and wants to do something with the result set before returning, now he has to find all of the return points.
Having multiple return statements may be easier for you to write, and less “lines of code”. But as someone who has to maintain others code, I often find myself having to wind my way out of a spaghetti of loose practices such as this. Yes, if your code only has a few lines, having mutiple returns wont be a problem. But where do you draw the line? It is better, IMHO, to stick with the old rule.
I agree with Dave.
In well-factored code, early returns are fabulous. I use them all the time to dispose of contract violations and degenerate cases, so that the method code can focus on the interesting part of the problem.
They can also be nice when expressing a simple set of rules. E.g., in a Java equals method, I often find it much more readable to express it as a series of “if … return” lines rather than one giant boolean expression. And I’m sure they have other uses as well.
In ugly code, I do think they can make things mildly uglier. But I think the solution there is refactoring for clarity, not adding rules to try to make mud slightly less dirty.