There’s a rule of thumb that is peddled in some (many?) circles of programming that goes a little something like this:
No function should have more than one return.
I’m not sure I understand why that’s an effective rule of thumb. As far as I am aware, this rule of thumb was invented during the “structured programming” revolution, when it was generally decided that program design should be “structured”, long before the “object oriented programming” revolution came into its own.
As I said in Signs You’re Doing Something Wrong (Part One), I tend to follow rules of thumb as much as reasonably possible unless and until I fully grok them. Usually, such “rules” should not be strictly observed at all times — they are just good guidelines that, from time to time, definitely need to be ignored. In many cases, however, it takes an expert to know when and how to ignore them without screwing the pooch. If I don’t fully understand the reasoning behind a given rule of thumb, I figure I don’t know when or how it should be ignored, and as such I try to avoid ignoring it.
Of course, there’s a difference between failing to fully understand something and failing to see any value in it at all whatsoever. For many people, much of the time, utterly failing to see any value in something is a sign that the people in question are clueless idjits who aren’t able to reason their collective way out of a paper bag with a flamethrower in hand. I make an honest, diligent effort to understand things, however, in a reasoned manner — and as such, when I utterly fail to see any value in something even after scrupulously seeking out the value in it, I tend to guess it’s actually pretty valueless. Thus, once in a while, I come across something that someone would like me to believe is a good rule of thumb — but it is, in fact, nothing of the sort. It’s very, very rare for that to occur, however, and there is always some clear indication of why such a failure of reasoning came about in the first place that explains its existence.
I’ve been digging around for some indicators of the value of the rule of thumb stating that no function should have more than one return. I had some vague ideas all along for why that might be valuable sometimes, but not enough to know why it would be valuable often enough to serve as a rule of thumb. As such, I figured I should try to follow it (but not sweat it too much if/when I fail to do so).
Recently, I came up with the following notions as a result of some reasearch and thought (research being the act of searching for, and reading, discussions on the subject online):
- The abjuration against multiple returns in a function may have originated with C programmers who released resources at the ends of functions. Subsequent additions of returns earlier in the function would have resulted in memory leaks. In many languages created since then (Perl comes to mind, as do Python, Ruby, and even Visual Basic) where it almost takes a conscious, concerted effort to create a resource leak, this isn’t really relevant.
- A possible problem with multiple returns is that such practice creates an implicit else conditional structure — one that is “invisible” rather than explicit and easily recognized. In very short functions, this isn’t such a problem because the way the return affects the structure of the code is obvious, but in longer functions readability may potentially begin to suffer. There’s nothing to prevent using an explicit if/else control structure with your multiple returns, though, and this explanation for the objection seems weak and inconstant.
- Use of a single variable, local only to the current function, that is passed to the return statement at the end of the function provides a more searchable decision path. Maybe.
Ultimately, however, I think the answer for which I’m searching might involve a reversal of the statement itself. It’s true that some of the above point at logical origins for such a rule of thumb that explain it, and some even apply somewhat to the present state of programming rather than being merely obsolete artifacts of a “distant” past, but none of them are compelling enough to really serve as justification for a still relevant rule of thumb as far as I can see. By reversing the causality of the statement in its phrasing, however, I arrive at something that looks at least initially relevant and true as a rule of thumb:
Each return statement should have its own function.
In practice, this would essentially manifest as an exhortation to examine a function (or subroutine, or method, or blah) with multiple return statements to determine whether they in fact indicate a need to turn the function into several functions.
What am I missing? Is there more to it than that? This, at last, strikes me as sufficient understanding of the concept to be able to make intelligent, educated decisions about when and how to use multiple return statements. Are there other components of understanding that I’m missing?