4 ms·
I'd love to hear your experiences as to how it leads to surprising and frequently hard-to-maintain code. I've found quite the opposite. Furthermore, I've foun
by jonathanwallace 15y ago
I'd love to hear your experiences as to how it leads to surprising and frequently hard-to-maintain code.
I've found quite the opposite.
Furthermore, I've found that early returns allows one, even in the original post's example, to easily specify a distinct error message for each case.
- cheald 15y agoMultiple return points are a signal to me that I'm usually (though not always) trying to encapsulate more functionality into a function than I should, or I'm using returns when it might be more semantically correct to use exceptions. I'm a big fan of the "each function does exactly one thing" rule of thumb, and when I start returning all over the place, it usually means that I'm starting to violate that rule. Except in the simple cases, multiple return statements usually means that I've got a function that's composed of multiple micro-functions, and can/should be refactored. Guard statements are an obvious exception. Sometimes you can't avoid it, especially if you're working with duck typing functions (which are a whole 'nother discussion), and it's not a hard-and-fast rule that multiple returns are evil. There are a lot of legitimate reasons to use them - performance being the primary one - and I would absolutely take them over an 8-deep nested if structure. But, they're often a warning sign that I'm putting too many eggs in that one basket.