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.
Have you stopped to consider why you can’t explain it better? Perhaps the reason is because you’re wrong.
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.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programmerhumor@lemmy.ml
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.
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.