Are multiple return points from a method good or bad?

Question

Given a coding standard with a maximum line limit of X characters, minimising deep nesting can avoid exceeding that length. Sometimes this leads to a code that looks like:

if (fail test)
{
   return(failed)
}

// continue
...
return(success)

In general, should a method only have a single return point, or are multiple ok? Ideally, please provide a technical basis for your answer.

Answer 1

There are places where having multiple exit points is acceptable. This is in highly optimized code that is close to the hardware. For maintainable code, it is much easier to read if you have a single exit point.

Answer 2

There is a lengthy discussion of this issue here.

Answer 3

I thought this question was asked before. (It is, thanks ItsMatt)

Multiple exit points can make code more readable. Because it avoids the need for complex guards.

Answer 4

I'm not sure if I have any technical basis, but from a design pattern / standard point of view, I'd much rather have multiple return points in my code. Multiple return points keeps my methods shorter and easier to understand. The alternative is to set return variables with the return value and exclude code under using conditions.

From a performance point of view, I've heavily used Java and .Net without any issues.

Answer 5

I generally consider whichever option makes the code more readable, and understandable, to be the best. If you would need to have large amounts of code (more than a 2 or 3 lines) of code nested within another block of your method, returning early would increase readability.

I don't know that there is much difference technically between multiple returns and a single return when you look at things like compiler optimizations, so I tend to consider it strictly a style issue.

Answer 6

I'm working on a code base where then coding standard says it is not permitted to have multiple return points. However, the previous programmers seem to have avoided this by using something like the following style:

proceed = true;
if proceed then
    // do a bunch of stuff
    proceed = result of something;
endif
if proceed then
    // do more stuff
    proceed = result of more stuff;
endif
// maybe do more things here
if proceed then
    // ...
endif

Arguably, this is worse. I have difficulty following the logic, especially when they have interspersed logic in between that isn't controlled by the "proceed" variable.

My opinion is that it's generally okay for a function to have multiple return points, but like anything else this can be abused.

Answer 7

Predictability is more important than the number of exit points.

Whatever methodology you decide upon, stick with it. It makes it much easier for someone else to follow your train of thought.

However, many exit points could be an indication that your method needs refactoring. Likewise with deeply nested conditions and one exit point.

Answer 8

It's like the argument over "go to," there are some places where it is good, and some where it is bad. Downward go tos are harmless, it's the upward go tos that are deadly.

It's simply a matter of taste. If I was going to have a restriction of one exit point, I'd use a downward goto to get to it. Usually a single exit restriction was from the days when you wrote in assembler or something else and had to make sure that you issued the correct restore sequence for the caller. It can also be because one is using a language that did not support multiple exit points - Standard Pascal is one - and thus you could only have one exit, and it had to be the bottom of the routine.

Any such rule is arbitrary and is merely a matter of taste; it should not have any effect on how the program operates and in fact in some cases it might be better, especially where you have relatively complicated logic flows, that once the module / function / method / procedure has its answer or result, it should exit so you don't accidentally execute code you didn't mean to use.

Paul Robinson