What do YOU think of single vs. multiple routine exit points?

[Sporkman]

http://www.regdeveloper.co.uk/2007/1...e_exit_wounds/

Bloody code!

By Matt Stephens, the Agile Iconoclast
Published Tuesday 4th December 2007 00:32 GMT

It's amazing how some good practices limp on for decades beyond their expiration date. I still encounter people who insist that a method should have only one point of return - as if we're all still littering our code with GOTOs, and the concept of a "black-box" function was never invented.

The way these same people go on about multiple exit points, you'd think they were headlining in one of the grislier episodes of ER trying to patch up the latest guest-star casualty while predicting dire consequences for the patient as they lie, bleeding to death.

People who prefer the single exit point (http://discuss.fogcreek.com/joelonso...w&ixPost=31001) tend to feel very strongly about it. But the reasons they give have never struck me as especially convincing. The following stream of generic reasons reminds me of the cookie-cutter platitudes that they roll out at the end of the more nauseating US TV series that seek to emulate ER, over the soul-grinding background warble of James Blunt:

1. Bailing out early causes resource leaks. That's why we have the "finally" block. (If you're determined to have a single exit point, finally is the only way to achieve it. But purists take note, System.exit() still gets around it.)
2. Multiple exit points make code harder to refactor. Yes, because simpler, clearer code is always harder to maintain.
3. Multiple exit points is a return to GOTO and spaghetti code. Ironically, it's single-exit-point code that's the anachronism. The whole reason this misguided principle came about was the reaction to spaghetti code that was structured programming (http://c2.com/cgi/wiki?StructuredProgramming). In modern languages and runtimes, single-exit-point code is outmoded and can even be dangerous. For example, the ubiquity of exceptions means that no method is ever guaranteed to have a single exit point. Code as if it is, and you're asking to be caught out.
4. Bailing out early creates an invisible "else" clause. What rubbish. A guard clause such as this:

if (account == null) return;

at the top of a method is much clearer, than:

if (account != null)
{ // 20 lines of code
// (that are totally irrelevant if account is null)
// later...
}
// and out we pop

Sometimes, trying to weave your code into a single return point results in setting of pointless flags and excessive nesting of "if..else" conditions. It's like wrapping a paper napkin around a seven-dimensional helix and trying to read the agile documentation off it. Figuring out whether each block of code is relevant to the current program state becomes a game of lining up the curly braces to figure out where each clause finishes.

It's easier to simply say: "Hey, I'm halfway through a method but I'm done. I'm outa here!" Artificially stretching the program flow to the end of the method just results in misleading code: implying that a block of code is relevant to a given state when the runtime really has no business still noodling around in there. If it's time to exit a method, exit the method already.

Adhering to an outdated maxim like "single exit point" results in a "one size fits all" approach to programming, which is hardly a good thing. But religiously hacking in multiple return points would of course be bad as well. If in doubt, go for the simpler, more expressive option which best communicates what the code means. It's more an article of faith than anything else. It's important to be able to take a step back and make a rational judgement call: this alone helps sort out the thinkers from the believers.

[LaRoza]

In my limited experience, multiple exit points make sense if done very early and for a good reason.

Randomly scattering them throughout code is probably a bad idea, but they can be useful, especially if they make the code more clear.

[Wybiral]

It depends... It's OK to make exceptions to the "good practice" rules when you're writing low-level software. If it's more efficient, some programs are OK to sacrifice "good practice" in order to achieve the performance they require.

That being said, most of us aren't writing such performance critical code as to warrant abandoning good practice. IMO, unless performance is critical, if your code requires GOTO, premature exits, globals, lack of exception catches/throws (if your languages supports them). Then you probably did something wrong during the design process.

[CptPicard]

I am so in support of the arguments expressed in the OP. Religiously avoiding "premature" exits leads to needlessly complicated code. Of course if, for some clean-up reason, you shouldn't exit inside of the function, then you shouldn't. But that's a call for the programmer to make.

Personally I have always found that if your function arrives at some returnable state at some point, it's just cleaner to return it immediately without saving state and explicitly unwinding out of your logic so that you can then return the stored state at the end. It's just confusing to wait like that.

I actually had a TA complain to me about this during a project we were doing for school... she came from business school and had been told that there ought to be just one return at the end of the function. She was pretty adamant about this in the face of like 6 of us CS majors, so we took a quick poll of students and other TAs and found that "immediate return" was favoured by a huge majority.

[raul_]

If it makes sense I always make multiple return points. I don't see anything wrong with it. actually I find it pretty straightforward.

I think that the reason one's code is messy, it's because it's a mess everywhere, not just the return points. So, early planning is as valid as for the rest of the code.

I think there is no unquestionable rule in programming, just things that work. They can be easier or harder to read, to maintain, to extend, but in the end, all that matters is that it works and it does what it's asked.

And if efficiency is asked, you should do the math with it too

[evymetal]

If you've got a functional design or an itterative function then I would definately use multiple exit points.

For longer, non itterative code I often avooid it - I don't know why but it just doesn't "feel" right sometimes, I guess I am worried that I will later add an important manipulation at the end of the function, it will run fine, until the 1 time in a million that a particular condition is met, the function returns early, and that final transformation isn't done. This is especially true with numerics.

[slavik]

if statements cause your code to branch.

[samjh]

Agreed with the article author.

I've never fully understood the reasons behind single-exit-point-only doctrine. Sometimes multiple exit points result in clear and simpler code.

There is the obvious caveat that developers need to be careful about the manner and positioning of their exit statements, but that always applies anyway.

[bobrocks]

Agree with the article author.

I much prefer to work with neat code that contains multiple exit points than messy code that has just one, I don't have any problems understanding it.

[Wybiral]

I've never fully understood the reasons behind single-exit-point-only doctrine.

IMO it's a convention. The same way indentation conventions and naming conventions don't actually HURT the program, but they make the code more manageable by having a set of guidelines. The problem is that they're too easy to abuse and result in a form of spaghetti code (where you can't trace the return point of a function) and can often create misleading results during the testing and debugging process. The way I see it, it's OK to use them when you have to. But if you do, you need to comment very explicitly how and why it's being used.

I also think another reason is that in most languages (but certainly not all), it just smells bad. It's a good sign that your code isn't modular enough or that you went about your design in a non-transparent way. It's fine when you need the efficiency, or when you write yourself into a corner, but it might be a sign that you need to step back and look at your design for a second, because there's probably a more elegant way.

But, I also think it applies more to higher-level languages. In most low-level languages it's probably going to be much more acceptable than in higher-level languages (where there are almost certainly more elegant and readable solutions). I'd say the same goes for things like globals, lack of exceptions, and goto's as well.