this post was submitted on 09 May 2024
445 points (92.2% liked)
Programmer Humor
32558 readers
415 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.
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.
Clearly I'm not referring to an if/else by saying two blocks. Even in my original example I show the exact issue. You don't understand it. I can't explain it better.
Have you stopped to consider why you can't explain it better? Perhaps the reason is because you're wrong.
Your toy example does not show the issue you think it shows. You've moved your cleanup block away from the context of what it's cleaning up, meaning that you've got variables leaking out of their scopes. Your cleanup code is now much more complex and fragile to changes in each of the blocks its cleaning up after.
You tried to use your toy example to show A is better, but then we showed that actually B is just as good. So fix your toy example to show what you actually want to say, because everything you said so far depends on you setting different standards for each scenario.
Yes I have. You've already assumed I'm not too bright more than once and worked from there. There's no point in investing more work on my end. If what I said worked, good. If not, that's fine too.
Now that's the pot calling the kettle black.
What work have you even invested? You've just repeatedly restarted your original stance. But sure, whatever.
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