Makes maintenance simpler; any resource cleanup can go through one point and you can see that it is correct when modifications are made. (C++ gives this to you with destructors, mostly).

Also makes it easier to step through code ("I'll just set a breakpoint and see what this function returns...").

I usually advocate using early returns for near boilerplate things like parameter checking, then a single return that does cleanup and exit, with 'goto' encouraged as the proxy for a return-in-the-middle. I think of it as similar to what a C++ compiler does for you.

These days I code for maintenance, since someone /is/ going to go in and start adding early returns and subsequent bugs. Plan for code rot.

It was part of the structured programming dogma. One entry point, one exit point. Multiple return was lumped in with using goto.

I never use goto, but I often use multiple returns similar to the examples in this article.

I have sadly code reviewed many pieces of code with the nesting problem.

if you have to use C++ without exceptions (console video games), then goto is much needed to handle exceptional situations locally. For example there would be label "fail:;" or "out:;" at the end of the function, where release of resource would happen, and you would "goto" to it, rather than releasing the resources in multiple exceptional places and return from there.

Interesting. I rarely program in an environment without exceptions, so I haven't had reason to adopt that style.

I recall that Linus has advocated the use of goto in the Linux kernel for similar reasons. And the goto version of this code does seem more readable to me: http://kerneltrap.org/node/553/2131

If you are using C++ (even without exceptions), then RAII (Resource Acquisition Is Initialization) with resources freed in local variables' destructors is a better solution.

Why don't console games use exceptions?

No compiler support on one common system.

You should be handling every case anyway - by the time the code is done, there are no exceptional situations left ;)

Far easier to do stuff like 'assert(postcondition)'