Exiting functions using return / exit sub statements

Question

Back in the day when I was learning programming theory at the university, I was always told that it was bad practice, taboo if you will, to have more than one exit point for a function.

As I have programmed more an more in the real world, I have come to the conclusion that not only is this not always the case, but in many instances it has made my code much more legible by placing exit conditions at the top. This reducing the amount of "arrow" code I write.

I have heard that a lot of this argument comes from C where you would run into memory leak bugs because you would forget to clean up at those exit points.

The other explanation I have heard for this commonly taught practice is that if I have to have more than one exit point, my functions are too long. I completely disagree with this argument.

Do you support the argument that all functions should only have one exit point, or do you think it's OK and in some cases good to have multiple return points?

Duplicate of Should a function have only one return statement ? which has already some other duplicates like Single return or multiple return statements? [closed], Are multiple return points from a method good or bad? (mmm, not closed), and so on. Already a number of answers to study -- PhiLho

Answer 1

No although this is very similar to an existing question... Bottom line is that having structured, early exits from a a method or function can make the function much cleaner and more readable, by eliminating the need for multiple nested if - else clauses and/or switch statements. When used appropriattely, this technigue is a good one.

Answer 2

Many times these type of statements are guidelines rather than unbreakable rules. In the real world you have to make judgement calls about these type of rules. If you have the need to do multiple exit points and you can se why this makes your code better then I say do it.

However, having said that, the guidelines are there to help us keep our code structure clean. So unless there is a reason to break them, don't.

Answer 3

I find it useful to link to the dupe:

http://stackoverflow.com/questions/36707/should-a-function-have-only-one-return-statement

Answer 4

I refer to "code complete" with my answer. Its the debate around gotos / exit statements / return statements - should you use gotos in code. Like you rightly say, this used to be an issue in software development that needed manual memory management, but thanks to the Using statement in the dotnet framework, the memory is managed while retaining readability. Code complete says...

putting the focus on avoiding gotos isn't helpful

McConnell gives examples of trying to exit a loop, and another where an object is being tested for errors before it is processed. By removing the "goto" logic actually the code creates Boolean logic that makes the overall appearance harder to read.

This isn't to say we should all go crazy breaking the flow of the program. Keep the methods small - it's easy to spot an Exit statement when there are only a hanful of lines in the method. I don't think goto statements are necessary in dotnet because of the exit / return commands.

I myself find that replacing this style of coding is not necessarily a hard task, and only a few lines of code are added to the application by building up a result before you return the statement but there are performance gains from returning a function early.