Apparently, PragDave recently questioned the conventional wisdom about GOTO considered harmful (does this mean all “X considered harmful” articles will be retrospectively struck off the record?). Ivan Moore’s given an example as to why the rule of “a single exit point” sucks, and I agree.

Another reason for multiple exit points is guard clauses. Code units, like classes or functions, ought to look right at a high level. Just like with a piece of writing, it’s important that the overall structure gives you the big picture. Guard clauses help here. You can say, “Okay, let’s get the cruft out of the way - the trivial cases, the exception cases - and now we can focus on the main thing the function’s meant to do.”

[java] void foo() { if (nothingToDo) { return; } // Implement typical behaviour of foo() } [/java]

is much more readable than:

[java] void foo() { if (!nothingToDo()) { // Hold my breath until the end // ugh The typical behaviour buried in an if-clause // And adding insult, we’re now indenting more than we need to } [/java]

Steve Freeman points out, Ivan’s particular example could be refactored nicely into a single ternary operator statement. While they don’t scale to larger, more complex, functions, ternary operators are a very handy tool for the reason he explains.