At first I thought this article was talking about returning just one value from a function, as opposed to say, an object or a tuple (e.g. things that feel and look great with ES6 destructuring).
Alas, the question actually describes a practice I've never seen nor heard of. Maybe I'm just too young.
Some of these ideologies are probably less applicable as your abstraction level increases. When you are writing low-level ASM, notions of return/entry points are critical. When you are writing C#/Java/Rust/et. al., these considerations are below your current level of abstraction and hurt more than help.
Whether you use one or many return statements from a method written in a high level language would depend wholly on the nature of that method's implementation and context of use.
And here I thought I was going to read a screed against using captured continuations to jump back into a function invocation that has already returned.
Actually, that probably ought to be avoided in most cases, come to think about it...
I've seen peopl go to great lengths to have only one return keyword. Unreadable mess with a "retval" variable declared at the top and then you have to read EVERYTHING to identify all the places it could change, and then figure out which of them (there can be multiple) changes it..
A return statement IMO makes it much more clear that "yeah, we're done under this circumstance"
I think it comes from someone mistaking "keep it simple and easy to read" with "ALWAYS THAU MUST DO THIS AND NEVER THAT!"
It's too bad goto has been so demeaned. It's great for "we're done here but I always want to do a few things before we exit". Like logging. That's it actually why I always work to a single return. I like to know, right before I exit, that I can clean references up, or write to a log, or whatever and that only has to happen in one place. If I'm patching some legacy code, I won't usually refactor to achieve this, but I might.
When I come across a situation like that, i consider the chunk of code reusable and split it into a separate function. It may not be perfect and you might need to make that function more generic than it was but I think it makes sense.
Various C/C++ programming safety standards (such as MISRA C), specify a single return only.
[0] is probably the best defense of the position I could find quickly, but the example used is convoluted, and very much "look what happens when you allow multiple returns".
I personally like to use early returns as guard statements when I'm doing precondition checking or on errors.
12 comments
[ 4.7 ms ] story [ 35.2 ms ] threadAlas, the question actually describes a practice I've never seen nor heard of. Maybe I'm just too young.
Whether you use one or many return statements from a method written in a high level language would depend wholly on the nature of that method's implementation and context of use.
Actually, that probably ought to be avoided in most cases, come to think about it...
A return statement IMO makes it much more clear that "yeah, we're done under this circumstance"
I think it comes from someone mistaking "keep it simple and easy to read" with "ALWAYS THAU MUST DO THIS AND NEVER THAT!"
The code shown with the if with two returns I think adds cognitive complexity - there is no need for the else.
[0] is probably the best defense of the position I could find quickly, but the example used is convoluted, and very much "look what happens when you allow multiple returns".
I personally like to use early returns as guard statements when I'm doing precondition checking or on errors.
[0] https://spin.atomicobject.com/2011/07/26/in-defence-of-misra...