3 ms·
I like this ergonomics argument, particularly from a reader's perspective. But having had to read some single return value code recently, I found that the retu
by camgunz 11y ago
I like this ergonomics argument, particularly from a reader's perspective. But having had to read some single return value code recently, I found that the return value returned at the end of the function was rather unhelpful; it usually boiled down to "return rv;". I then had to go back up to the top of the function and follow through the nest of passed conditionals and side effects, fall throughs, and failed conditionals to see how "rv" was modified throughout the function. The non-linearity cost me a lot more thought, whereas with multiple return value code the failed conditionals are "tossed" out of my head very quickly. I think, given that you almost always end up reading the whole function anyway (which is probably good), linear is better than non-linear and consistency (bail early) is better than inconsistency (anything goes) when it comes to error handling.
- phamilton 11y agoI come from an FP background, and so I tend to avoid multiple assignment as well. In such a scenario, there's a single line that assigns rv. Each of the variables used in assigning rv are each assigned just once. I can follow the graph fairly easily until I get to the bit I need. Often its something like "what conversion rate for currency are we using?" and following that chain gets me there quickly.
- camgunz 11y agoYeah, I can definitely see how if you're disciplined it can be effective. But in my case, I've seen integer return values hold status codes from multiple modules and libraries, file handles, and enum values all in the same function just to twist everything together so that no matter where it stops executing, "rv" has some kind of value so that the ending "return rv" won't just return success. It was total madness, and it's really hard to do anything as complicated and fragile as that with early returns. I will admit though that no programming style will sufficiently protect against bad coding :). I'm sure even if this person did everything I advised, they'd still find a way to overcomplicate and confuse things. So maybe the issue is moot, or at least bigger than style.