Thou Shalt Have One Exit Point Per Subroutine -- A Monkey Cage Conundrum

Back when I was a wee lad in Engineerin' school, fussin' with alloc and malloc and all of that hurty stuff, a particular lesson was drilled into us:

Thou Shalt Have One Exit Point Per Subroutine

This was given as gospel and we learnt it as such. It was such a fundamental principle of the coding style they drummed into us that the reasons for it were glossed over quickly -- "it make's maintenance easier".

I stuck to that principle for years -- until finally I thought about the underlying reasons, the trade-offs involved, and realised that the benefits were redundant now. The rule had become, mostly, bunk.

Yet, every time I write a subroutine that has more than one exit point, I find that other monkeys in my monkey cage jump up and down and screech and throw excrement and chatter excitedly.

The psychological aspect of their behaviour was opaque to me until recently when Phill Haack pointed out a particular monkey cage experiment.

So go and read about that monkey cage experiment now. I'll be here. Grinning demonically. Then we'll continue.

Well said! I think this relates to the Fail Fast school of thought too. Now I can point to this post when I defend multiple return points from a method.

I think some of the single-exit-point dogma also stemmed from the large routines that we, er, routinely used to have back in the Olden Days. These days I seem to write mostly teeny-tiny methods that might have a guard clause or two, complete with early returns, so it just doesn't seem to be an issue.

I still feel kind of naughty when I do it though...

I was talking this exact thing yesterday. The argument FOR one exit point per subroutine was "maintenance." On the other hand, one of the primary reasons that Code Complete recommends returning early is to enhance code readability.

Like you said, with better tools for the job, the memory management reasons are no longer valid. Without those reasons, I would say that readability now equals maintainability.

For your information:

Horse & carriage drove on the *left*, not the right. Walking on the right was for peasants -- they needed to see what was coming, so they could jump out of the way.

In the UK, that custom persists. In France, however, they took to decapitating the upper classes, so the upper classes took to riding on the right, and then Napoleon started work on a pan-European road network.

So now you know.

I agree that long routines were more of a factor than memory management, at least when it was being drilled into my head. I still actively avoid any returns more than 5 or 6 lines into a method (ideally only the first lines are guard clauses).

Of course if I really really need to return in the middle, then I really really need to split that out into another smaller method.

What about retValue/result variables? Anyone still think that idiom has a purpose? I embraced it for awhile, but I've noticed that I've stopped using it lately.

You know I love your blog, but there I find a little bit of resistance having to break out of my RSS reader to read the second half of your posts. In this case, you did mention that it is continued, but sometimes you don't, and I wonder why it doesn't make sense. Anyway, this is a longhand way of say stop it; put the whole post in the RSS feed and I'll be a happy reader. Thankyou ta.

@Simon and Kev -- thanks -- i do agree but i have some technical issues with putting the full text into the rss feed.

the rss standard doesn't like it if i include inline style information in the feed -- but this is something i personally enjoy doing.

hence i have to either emit invalid html for rss (bad!), or prepare a separate html file for the feed (bad! 'DRY') or have it programmatically remove inline styles (fun, but will take a little testing) or stop emiting styles (bad... i like writing styles).

help me dear abbey.

lb

I'm a fan of single exit and try to implement in all my code. It may be more verbose, especially for smaller functions, but the maintenance argument is definitely true. It's easy to miss updating, removing or checking a return statement if there's multiple returns in a long function.

I do agree with checking the failure conditions at the top, but sometimes you simply can't do that and must wait until later on. Sure that may mean you have a long function, but sometimes you just have long functions with no need to split it up.

Long functions are evil - and even more with extra nesting and temporary variables needed to have only one exit point.

I'm completely in favor of exiting when needed. I've always programmed with multiple exit points and never ever felt any pain.

I absolutely hate the type of flow you get when people insist on having one exit point above all other considerations. Really. Just break these long functions into smaller ones and get going.

Yes I've programmed in C and No I've never had memory leaks (in three years of maintenance, we only had one bug).

Multiple return points begin to be painful when you have to run code coverage tools, to prove that you have tested the code thoroughly.

This is only anecdotal, but on one project where we were required to show that we had achieved at least 95% code coverage, we found that modifying the code to use a single return point at the end of each function/method made this testing substantially easier.

We also found that rewriting the code in this way resulted in much clearer code.

The only time I would encourage the use of multiple return points is for bottleneck code when you need to squeeze for performance, and returning early is vital. However, with today's compilers and the use of the 'break' keyword, I would imagine that multiple return points would still be largely unnecessary.

Personally, I still think there is a case to be made for single-point returns.

Often, but not always, it makes the logic clearer by the reduction of control paths.

Secondly, not all invariants entail objects that need to be cleaned up. They can be incrementing/decrementing counters, adding/removing from lists etc. In these cases you would have to add redundancy in order to have multiple point returns.

By the way, D (http://digitalmars.com/d ) makes this really comfortable, with scope(exit/success/failure) allowing you to clean up a ressource right where it's allocated.
Example:
void test() {
auto foo=malloc(100);
scope(exit) free(foo);
/* much code and returns */
}

Not that I'd normally use malloc in a D program, but you get the idea :)

--FeepingCreature, rabid D fanboy

I agree that there's nothing wrong with multiple exit points, but single exit points are still easier to read.

Personally, I like it if I can chain it up so that a conditional is the last expression in a function, best of both worlds sorta.

"I agree that there's nothing wrong with multiple exit points, but single exit points are still easier to read."

That sort of thing is a large problem in our business. People just throw out unsupported assertions like that with absolutely no evidence behind them. Basically we're supposed to take somebody's personal prejudice and enshrine it as a universal law.

Well, forget it. Show us the usability studies or just shut up.

"Well, forget it. Show us the usability studies or just shut up."

Well, are there any usability studies for the opposite case you'd care to bring?

I believe that it depends on the nature of the function. The case for multiple-exits is particularly strong in, say, a validation function. I want to test if someone gave me a valid input. Depending on the language, I can test it for variable type, string length, regular expression tests, evaluates to a scientific notation number in the range X to Y, etc.

But if my function contract is something like "Return true if valid, false otherwise", then it makes a heck of a lot more sense to have early return-false statements than to have some sort of "isok" flag which every single subsequent test must know to skip if it's been set earlier in the routine.

I blogged about this nearly 1 year ago, http://javathink.blogspot.com/2006/10/invert-your-logic-part-2-for-loops-and.html, and Haacked linked to it in April from this post: http://haacked.com/archive/2007/04/20/write-readable-code-by-making-its-intentions-clear.aspx

I bet the monkey experiment is some bogus urban myth which is useful to prove a point even though it isn't true. Same as the "Boil a frog slowly and he won't jump out" one.

At least I hope it isn't true. Who comes up with these kind of experiments? I'd be one pissed off monkey if people were trying this on me.

yep - the frog boiling is indeed a myth!

http://www.snopes.com/critters/wild/frogboil.asp

http://uclue.com/index.php?xq=801
after a lot of research, pinkfreud says:
"the experiment ... is almost certainly fiction"

check out this excellent query they use to find it referenced in books

http://books.google.com/books?q=monkeys+bananas+%22cold+water%22

(the aim here is to find a 'first source' -- and then if that can be debunked, the myth is busted.)

(p.s. seems i can't read my own captcha)

Thou Shalt Have One Exit Point Per Subroutine -- A Monkey Cage Conundrum

We're Finally Using the Right Tools

Articles

Twitter, baby

Recommended Reading

Recommended blogs

Aggregated Links

Human Link Machines