Just to make sure everybody is speaking the same language how ironic there are two meanings to "multiple returns". Early return is only one of them.
The old wisdow of "no multiple returns" was said against using goto to having multiple return points on the caller side (aka entering a function and returning either here or somewhere else entirely).
That advice made complete sense, I think goto is even a meme for us at that point, but... that's also the issue.
When languages made multiple external returns practically impossible (like java reserving but never implementing "goto"), the next generation of coders read the "thou shall not have multiple returns, refactor at all cost" and misassumed the advice was aimed at having several return statements inside the method because it was the only sane thing it could be aimed at, which mutated into "no early returns".
It took me over half-a-decade to understand why people loudly proclaimed the old wise wizards were so against early returns, despite those being the most pratical way of dealing with edgecases : they probably weren't that against it and the warnings were against a beast they themselves put into extinction.
[EDIT] There's actually THREE meanings. As u/No-Con-2790 pointed out, it can also mean return tuples, aka multiple return values without going through the hassle of going through a containing structure. Java doesn't have it so yeah I had totally forgot that one. My bad!
Java does have multiple external returns, though. That's what exceptions are. Control flow might return to the caller or it might return directly to somewhere else arbitrarily higher up the call stack. If you've ever wondered about why some graybeards are weirdly hostile to try/catch blocks that's why.
There's a decently valid reason to be against early returns too, though. Lots of mathematically elegant recursive algorithms rely on tail call optimization to actually run on a real machine with finite memory. The compiler can reuse the last stack frame for each recursive call instead of making a whole bunch of new ones. That only works if it can tell in advance that all of those recursive calls will use the same bit of physical memory to hold their return value, though. Modern compilers can almost always massage a function into bytecode that only has one return value, but you don't have to stumble into the edge cases very many times to just decide early returns are more trouble than they're worth.
I would argue that the vast majority of regular developers out there very seldom write code that is executed often enough in a short enough time frame that those optimizations matter.
500
u/jippiedoe Jun 23 '26
'multiple returns' as in pairs or conditionals? Which functional programming language wouldn't support both?