I can't agree to this. Throwing exceptions is a kind of "returning early" (though not in a normal way) and it has the same effects on control flow. Yet nobody would argue for throwing exceptions at the end of methods whenever possible (one could have a local variable to keep the exception and throw it only at the end). So why is returning a result different? If you are at a point where you are completely sure that you know the final result of the method, you might as well return it. In fact, I don't even think that it is true that the control flow becomes objectively simpler with late returns. You will process exactly the same lines of code, with the exception of the final return (that you did earlier). Indeed, why would you execute any code after setting the final value for your result variable? This should hardly ever be necessary. So you always have to set your return variable in a control structure like a switch, if-else-if-chain, or loop that you leave as soon as the result is found to make sure that the result is not set twice. A problematic type of code is the one where the return variable is re-set multiple times on purpose, in a "last one wins" fashion. This forces you to trace the life of the variable to find out what will be the result. It is easy to make errors in such a flow.

A notable exception are all cases where it is natural (or necessary) to modify the result a number of times (building a list; conditionally adding to a string; etc.). It could also be more readable to split the computation of one result into separate lines (like when building a hash code the pedestrian way).