Should methods always return from one place?

Question

Possible Duplicate:
Where did the notion of “one return only” come from?

I got into a little argument with a coworker about whether a method should be written like this:

public Thing getThing(int key){
    if(!things.containsKey(key))
        return null;

    return things.get(key);
}

or this:

public Thing getThing(int key){
    Thing t = null;

    if(things.containsKey(key))
        t = things.get(key);

    return t;
}

I personally think the first way is cleaner and easier to read. However, I was taught in school that you should always return from one place. Since no one has ever been able to give me a good reason to prefer one over the other (baring stylistic concerns), I usually go with whatever makes the code easier to read.

Are there any good reasons to prefer one way over the other, or does it vary by situation?

Answer 1

Should methods always return from one place? NO.

Should I never use goto? NO.

Should I never inherit form non polymorhic types? NO.

There are lot of questions like these, that lies like sediments in the history of the computer languages, creating sort of sectarian cultures (not to call them even Religions) where everything must be Pure, Intact, Elegant, Virginal, ...

Luckily the most of "humans" (in "humanist" sense) don't follow this rules, otherwise humanity had already been extinguished for the practical impossibility for people to meet themselves. (out of metaphor: program must also work, not just be elegant!)

All of these rules comes from philosophies of the languages with all the good intention to keep things in order, but that may fail dramatically when such order becomes a mania.

I personally avoid to trust teachers or mentors that create their leadership abusing of little words like "always", "never": whatever great their experience can be, they cannot have the knowledge of the everything and every-time.

Avoiding spurious retunrs can be a good thing, but doing it introducing 4 variables and 5 level of if-nesting is bad more than a multiple return.

Goto randomly up and down jumping arbitrarily into code structures is bad, but introducing a network of fake variable states to avoid goto-s to describe a state machine is even worse (since it makes you anymore able to identify the states, that can easily defined as jump labels)

There was a time (try search a listing of a BASIC program of the '80s) where variables didn't have a scope, where labels where just numbers, where if could only do a goto. Jumping in the middle of the loop skipping index initialization, or modify a loop index from within a called subroutine, or jumping in the middle of a function from the outside was the major source of mistakes impossible to be found, inside code written for the machines, and not for the maintainers.

But today variables have scope, goto-s have scope, function call have scope. All of those "tool" have very well defined influence limits. The problem is not avoid this or that tool, but use the right one, in the proper place within its proper limitations. Language features exist for a reason! Don't drop them just for purity: drop them when they don't help you.

When coding something, also thing to the possible variants: What should I modify if my spec. change this or that way? What (between this or that) will be the most probable "next requirement" from my users/clients/bosses ?

Once you did a reasonable prediction, code in a way what you will expect to furthermore change, can be easily found, and can be easily changed without too much "things at contour" to look around an change as well. 5 levels of if, to avoid four returns is in the most of the case not the way to go, since it risk to make all text to be modified if another escape condition is required to be introduced.