TomBecker.net

Multiple Exit Statements, The Great Debate

A coworker asked me about a function he was working on that lent itself to multiple exit points, and I tried to push him in the direction of having a single exit point at the end of the function, and using a local var to hold the return value.

I suggested that by doing so he increased style and readability. And after I told him that I kinda thought that my response lacked any sort of real substance. It was kinda just saying, 'because I said so'. But who am I to say what style is? So I thought back to my programming classes and how we always did it that way, without any real reasons why. I guess you could say I was what this article called a 'structured programming purist.' Sure I may have slipped a few return statements into one function here and there, but it always felt that I was cheating.

So I went looking for a article that could explain why exactly one return statement should rule them all (very proud of myself for working in a LOTR reference). I came across a plethora of articles that all pretty much said the same thing.

There was a time when multiple returns were not good because of memory management. Since you had a single exit point you knew were all of your objects were getting cleaned up and you would miss anything as explained here. But in the newer programming languages with managed memory this isn't an issue. Especially not with try/finally blocks and using statements. The same article had another link to an interesting experiment dealing with monkeys.

It basically says that monkeys will do things because that is that is the way that it has always been done, even if they have no idea why things are being done. So I'm through being a monkey, Multiple exit statements are OK in my book; just don't tell my old professors.

---

PS. Best article I've written...LOTR and monkeys? awesome

Labels: .NET

posted by Tom Becker at 9/11/2008