You're viewing a single thread.
Uses multiple returns... I'm switching to Windows.
You mean you are early-returning to windows, uh? You can't do that by your own rules.
Fuck.
What's wrong with multiple returns?
Maintainability.
You can't read a block of code and as quickly and understand its control flow without reading every line, especially in regards to resource cleanup.
For example say you have:
... if this: something or other and many more... ... else: yet another thing and some more ... do some cleanup return ...Say you aren't exactly interested in what happens inside each branch. If you can assume that there's one return at the end of the block, you can see the
ifandelse, you can reason about what values would trigger each branch, you can also see that no matter which branch is executed, the cleanup step will be executed before returning. Straightforward. I don't have to read all the lines of the branches to ensure the cleanup will be executed. If I can't assume a single return, I have to read all those lines too to ensure none of them jumps out of the function skipping the cleanup. Not having to think about such cases reduces the amount of reading needed and it makes reasoning about the block simpler. The bigger the blocks, the more the branches, the stronger the effect. You have one less foot-shotgun to think about. The easier you make it for your brain, the fewer mistakes it's gonna make. For all those days when you haven't slept enough.E: Oh also refactoring blocks of code out into functions is trivial when you don't have multiple returns. Extracting a block with a return in it breaks the parent control flow and requires changes in the implementation.
E2: Shorter blocks do not obviate this argument. They just make things less bad. But they make almost everything less bad. Shorter blocks and single returns make things even better.
If your function is so long that keeping track of returns becomes burdensome, the function is too long.
I'm not a fan of returning status codes, but that's a pretty clear example of early return validation where you can't just replace it with a single condition check. Having a return value that you set in various places and then return at the end is worse than early return.
I don't think it's worse, I think it's equivalent. Also I don't like the risk of resource leaks which is inherent to multi-returns beyond input validation. And that's true beyond C because memory isn't the only resource that can be leaked.
It's not about how readable the branches are, it's about having to read all of them to ensure you understand the control flow so that you don't leak. Length of functions is a red herring. You want me to read the contents of short blocks to ensure the control flow is correct. I don't want to read the contents of those blocks, other than the conditional and loop statements. Reading short blocks is better than reading long blocks. Reading just the control flow lines is better than reading short blocks.
And I'm going to make you read those blocks because they are there for a damn reason. What are you even reading at this point if you're not reading the preconditions? That's how you end up dereferencing null pointers, when you have ten nested ifs you can barely see it on your screen
You said yourself they're equivalent. You either have to read the blocks in both cases or neither case.
You need to read the blocks to know what gets returned (either early or in a single return). You need to read the blocks to see what resources get created but not released. What are you hoping to achieve by only reading control flow?
At least with an early return you can stop reading.
I meant assigning a return value then returning it is the sam as rnultiple returns. Anyway.
Right. Like I said.
What are you hoping to accomplish by only reading control flow and not the contents of the blocks? You keep raising concerns like not properly releasing resources, but if you don't read the blocks you don't know what resources we're allocated.
I think your argument depends on both having your cake and eating it.
Yes clearly someone has to read the blocks at least once to ensure they are correct.
In subsequent reads, when I'm interested in the second block out of two, say during a defect analysis, I don't have to read the first one to be sure I'm going to reach the second. I can straight head for the second one and any subsequent stuff I care about. Multiple returns force me to read both blocks. I don't know what else to tell you. To me this is obvious and I think it's probably even provable. I don't know about you but I have to read a lot of existing code and every bit helps. We have pretty strict code style guides for that reason.
If you're reading the control flow, and the control flow tells you the first block isn't being entered, then it doesn't matter if the first block contains an early return or not, because it wasn't being entered. If it was being entered then you have to read it anyway to make sure it's not manipulating state or leaking resources.
To use your example: in subsequent reads, when I'm interested in the second block out of n, say during defect analysis, I can head straight to the second block in either case since control flow shows the first block was skipped - but in the case of early return from the second block I can stop reading, but in the case of a single return I need to read the flow for all subsequent n blocks and the business logic of any subsequent blocks that get entered. The early return is a guarantee that all subsequent blocks may be ignored.
To me this is also obvious. I've been doing this for quite a while and 95% of the time, reviewing and debugging code with a single return is far more tedious.
I hate it when some blame early returns for the lack of maintainability.
Early returns are a great practice when doing argument validation and some precondition checks. They also avoid nested blocks that worsen readability.
What's being described there is a function that tries to do too much and should be broken down. That's the problem, not early returns.
Early returns are very similar to gotos. One level of nesting to take care of validation is trivial in comparison. You're replacing logical clarity for minimal visual clarity. This is true regardless of the size of the function which shows that the size of the function isn't the determinant. You're not alone in your opinion, clearly, and I'm not going to convince you it's a bad practice but I'll just say what I think about it. 😅 This practice doesn't make it my team's codebase.
You can say any execution flow controls are like gotos - continue, break, exceptions, switch, even ifs are not much more than special cases of gotos.
This is true regardless of the size of the function which shows that the size of the function isn’t the determinant
Logical clarity does tend to worsen as the function grows. In general, it is easier to make sense of a shorter function than a longer one. I don't know how you could even say otherwise.
Early returns are still great for argument validation. The alternative means letting the function execute to the end when it shouldn't, just guarded by if conditions - and these conditions any reader would have to keep in mind.
When a reader comes across an early return, that's a state they can free from their reader memory, as any code below that would be unreachable if that condition was met.
I never said longer functions are not less clear. I said my argument is valid irrespective of the length of the function which shows that the problems I claim multiple returns bring are independent of function length. 😊
Any validation you can write with a few early returns you can write with an equivalent conditional/s followed by a single nested block under it, followed by a single return. The reader is free to leave if the validation fails nearly the same, they have to glance that the scope ends at the end of the function. Looks at conditional - that's validation, looks at the nested block - everything here runs only after validation, looks after the block - a return. As I mentioned in another comment, validation is a trivial case to do either way. Returns inside business logic past validation is where the problematic bugs of this class show up which requires more thorough reading to avoid.
If you gave me a PR with early returns only during validation, I probably won't ask you to rewrite it. If I see them further down, it's not going in.
Any validation you can write with a few early returns you can write with an equivalent conditional/s followed by a single nested block under it, followed by a single return. The reader is free to leave the validation behind just the same.
And that conditional indents your entire function one level - if you have more validation checks, that's one level of indentation per check (or a complicated condition, depends whether you can validate it all in one place). It's pretty much the case the other user illustrated above.
Returns inside business logic past validation is where the problematic bugs of this class show up
That much we agree. But again, this is not an early return issue, putting too much logic in a function is the issue. Rewriting it without early returns won't make it much clearer. Creating other functions to handle different scenarios will.
Again, if you can write it with conditionals and returns, you can write it with equivalent number of conditionals and a single nested scope. No further scopes are needed. The conditional will even look nearly identically.