Why should methods have a single entry and exit points?

Question

Looking around forums and the web, i have come across the advice that a method should have single entry and exit points. My first question is does the sinlge entry point apply to java. I can't see how a method can have an entry point other than invoking it and passing argumnets to it.

The second question is that why only a single return statement, is this for the sake of the clarity of the source code, or can the compiler/jvm optomize a method with a single exit point in a way which it can't with 2 exit points.

Answer 1

I assume that entry point doesn't mean for any given method itself, but instead a method that allows you to start your application -- a public static void main(String[] args) method. Having a single class with a single method that's always used to start the program makes sense.

Answer 2

It would be hard for a method to have more than one entry point...

As for exit points, I just use whatever gives the clearest code. Sometimes that's a single return point - at other times it makes a lot more sense to return as soon as you know the result, which may be before a whole bunch of other code... using multiple exit points can reduce nesting significantly.

Note that the "single exit point" idea made a lot more sense back in C, without exceptions and try/finally... it meant that you could put your cleanup code in one place without having to trace every exit path. With try/finally (and garbage collection) in C#, Java etc, you don't need to worry about this as much.

Answer 3

I'm not sure what it would mean for a method to have more than one entry point.

The advice to have only a single point of return is bad advice. Consider

public void uglyAndWrong(final int hamsandwich) {
    int answer;
    if (hamsandwich % 2 == 0) {
        answer = 27;
    } else {
        answer = 13;
    }
    return answer;
}

vs.

public void comelyAndHip(final int hamsandwich) {
    if (hamsandwich % 2 == 0) {
        return 27;
    }
    return 13;
}

Having a single return statement always causes otherwise unnecessary variables to spring into being. It often causes extra braces. I'd reject that advice.

EDIT: The comments and other answers are very interesting, and make me realize how much I take for granted my own milieu as a programmer. So I modify my answer to say: in the context of contemporary programming languages, the advice is out of date, and should be rejected.

Answer 4

Single entry point is an idea that dates to when the "goto" statement is still around. In languages that define functions, it's no longer an issue; it's automatically enforced.

I don't think single exit point holds in languages that throw Exceptions, like, well, Java. Having a single exit point for a method that throws even a small number of exceptions would turn readable code into a disaster zone.

Answer 5

I cant imagine another entry point beside a function call either.

The single return statement rule is for clarity. A function which has many different return statements is probably a good candidate for refactoring : break it in multiple functions. As for myself, I break that rule quite often for special conditions checking (which are very simple conditions) :

doSomething(param) {
    if (param == null) return null;
    //do some real stuff with param
    [...]
}

This feels perfectly clear to me.

We could also add that raising an exception is en exit point to a method. And raising an exception is a perfectly reasonnable way to exit a function when something exceptionnal happens.

I'm not a compiler guru at all, but I know that there is some optimization for tail recursion coming to Java. Tail recursion is when the last thing a function does is calling itself. And even that doesnt require that there is only one exit point in the function.

I dont think there is any performance reason to optimize the number of return statement. Readability is usually more important.

Answer 6

The stricture of having a single exit point is an instance of a good guideline turned into a bad rule.

If you have many return statements or other exit points in your code, it can make it difficult to read and reason about what it's doing and how changes can affect it. A long method with multiple return statements will likely be more bug-prone and costlier to change than the same method with one return statement at the end.

Of course, if your methods are long enough that they're getting tough to scan, that's a problem in itself - you might wish to break the long method into a set of smaller ones that are easier to reason about.

Instances where it makes sense to exit mid-method include:

• Input validation: It's acceptable to return immediately on invalid input, or on any input that's simple to evaluate and doesn't need to go through the whole method body. These returns should be clustered at the top of the method for readability, and the rest of the method will probably benefit from keeping it simple and having that single exit point at the end.
• Exceptions: If you've run across a problem where it makes no sense to do anything but abort the method and throw an exception, there's no need to wait until the end.

Finally: I'll agree with Jonathan Feinberg in that a method as short as he describes does not sacrifice any readability by returning directly rather than stashing the answer and returning later. Though brevity could be further enhanced by changing it to:

public void shortAndSweet(final int hamsandwich) {
  return (hamsandwich % 2 == 0) ? 27 : 13;
}

Which, funnily enough, takes us back to a single exit point...

Answer 7

Warning: C# code ahead! :)

IMO, as soon as you know there's a problem, or going to be a problem, GET OUT! Exceptions are also exit points. (Oh, and don't throw exceptions that you can't recover from - that's another bad thing I see a lot.)

public int MyMethod(IMyInterface someThing, int someOtherThing)
{
    if (someThing == null)
    {
        throw new ApplicationException("Why did you send me a null thing?");
    }
    if (someOtherThing < 0)
    {
        throw new ApplicationException("Great, now the value is less than 0!");
    }
    // Continue with code...
    return value;
}

Answer 8

First, I don't know how a Java method can have more than one entry point. Fortran has the ENTRY statement, which provides alternative entry points into functions and subroutines (different things in Fortran), and in internal constructs it's sometimes possible to do similar things internally (look up Duff's Device for a very good or very bad example).

Second, the reasons for single return points are stylistic in nature, and sometimes relate to attempts to reason formally about programs. I know of only one technical reason for it: having one exit point makes it easier for the compiler to check all execution paths, when that's important for warnings.

One traditional reason has been to make sure cleanup code is run, which simply doesn't work in languages with exceptions. In Java, cleanup code is run by try {...} finally {...}, and by RAII in C++.

Another reason has been to avoid confusion, as the code reader might have trouble understanding when certain code is run if there have been arbitrary returns. This is more valid, but in general handling simple special cases like invalid input and returning immediately makes the method more readable.

Answer 9

These pieces of advice were actually meant for programmers in the olden days when most iteration and branching was done with goto-like statements. They don't make much sense if you are using a modern language, but people continue to repeat them like a religous creed without understanding what they mean.

The basic idea is that if you have a subroutine you should not use "goto"s to jump into it at multiple places, nor should you use goto's to jump out of it at multiple places.

If you avoid goto's in modern langauges, the first isn't really possible. The second is possible with more structured statments like "return", "exit", and with exceptions. The thing is, they are well-defined structured statments. The subprogram's stack will get cleaned up just fine if you use them, and anybody reading the code knows just where control will go when they come across them.

Some folks still insist that exiting a routine anywhere but the very last statement is a Bad Thing. If that works for them, fine. But I really hate seeing code with boolean flags, temporary variables and convoluted nexted "if"s just to avoid a second return statement.

Answer 10

It a symptom of Cargo Cult Programming. Back in the day, when OOP wasn't mainstream, people had to be convinced that GOTO was a prime cause of spaghetti code. You could have code that had multiple GOTOs jumping in and multiple GOTOs jumping out.

A cry went out to find a solution to all the pasta-based code. OOP was on the horizon and definitely helped with inheritance, encapsulation, and overloading. But in the interim, it was declared that to solve the maze of twisty little execution paths all alike (but different), programmers should only allow one entry and one exit. On the battlefield of software, this was an act of triage to stop the bleeding. Now that we have objects, methods, public/protected/private, the Single Entry Single Exit (SESE) mantra is more like a tourniquet.

Making code easier to read should never be a bad thing outside of needing pure performance. Even then, the optimized code can be isolated and not allowed to become the standard coding style for everyday, barely use 1% cpu programs.

Answer 11

Forget multiple entry - once upon a time you could do it in Fortran, and you can still do it in assembler, but it's not really an issue now.

For returns, it's still an issue, and not clear cut. On the one hand, if you take simple LISP recursive functions and translate them directly into a C-ish language, it makes sense to have a separate return for each branch. There are also other situations where common sense will tell you it is sensible to have multiple returns.

Where a single return point is a good thing is where you want to be sure you will get a chance to take action before the function returns, such as doing cleanup. To put it more broadly, if you have two statements in a row:

Statement 1;
Statement 2;

It helps you to understand the code if you can be sure that if control gets to Statement 1, barring a crash or infinite loop, it will eventually get to Statement 2. It is easier to be sure of this if Statement 1 has no other way to finish up, other than falling out the bottom.

Answer 12

I agree with others here who say that SESE (Single-Entry, Single-Exit) is not as relavent as it used to be, but I don't think it's redundant.

Functions and methods with a single exit tend to be easier to reason about - especially if there are resources that need to be managed. Even in a managed environment there may be things that need to be done in a certain order.

Personally I do aim for SESE by default. If I'm finding it doesn't come easily, or it leads to unnecessary nesting or other complexity I see that as a code smell and investigate if I need to refactor in other ways - e.g. decomposing a longer method into smaller components that can each be SESE'd.

But even beyond that there are certainly cases where SESE is more of a burden than not. Typical examples are methods that check optional pre-conditions up front and return early if not met. But I very rarely (if ever) find cases where an early return is nested right in the middle of a method where it didn't make more sense to refactor.

There may also be scope for compiler optimisation. In C++ having either a single returning expression or a single variable that gets returned at the end may allow the compiler to do Return Value Optimisation which means it uses the instance of the variable the caller is assigning to, rather than creating a local instance. There is likely scope for similar optimisations in other languages.

Answer 13

I haven't much seen mentioned code size and performance. Personally I aim for a single exit point provided it makes sense, and from a performance PoV especially if there are large or expensive to destruct local objects involved. That code has to be inserted somewhere and I'd like it easy for the compiler to emit it exactly once. Likewise it makes sense to bail out before constructing those heavy objects. If a function returns an object (not a pointer or reference) it might help to construct it as an argument to (the single) return (return classname(args);). Exceptions should probably "naturally" end up together too, for it is usually better to check whether there was any error at all before watching for specific errors.

In my experience, if you get convoluted nested ifs and loops, multiple state variables, or more than a few exit points (returns, exceptions, longjmps, gotos, (come from)s, what have you) then it usually means it's time and past time to split the function up into its constituent logical parts, and doing that in turn usually makes it easier again to shuffle closer to SESE, but only as far as practicable.

To end with a possibly worn quote, it "should be as simple as possible, but no simpler". Here meaning that if a rule or guideline introduces unnecessairy complexity and makes it harder to read the code, it wasn't appropriate for the situation.