5 ms·
"Never use early exits" is exceedingly bad advice, in my experience. What has led up to your claim that early exits are bad? As I've gained experience, I find
by jemfinch 14y ago
"Never use early exits" is exceedingly bad advice, in my experience. What has led up to your claim that early exits are bad? As I've gained experience, I find myself writing code like this more and more:
if (UnexpectedOrUnhandledCondition(x)) {
...
return false;
}
if (OtherError(y)) {
return false;
}
and so on. Serial code like that is trivially easy to understand when reading; more importantly, six months later, it's far more explicit and easier to comprehend than the comparable single-exit version.
The alternative to early exits is nesting, and nesting is the readability killer. My experience has apparently been just the opposite of yours: that avoiding early exits is a sign of a junior programmer, and returning early whenever possible is a sign of an experienced programmer who knows that understands code maintenance.
- takeda64 14y agoAgreed. Same for using goto in C for error handling (e.g. http://www.xml.com/ldd/chapter/book/ch02.html#buierr http://www.xml.com/ldd/chapter/book/ch02.html#buierr) I found this used often in Linux kernel and I absolutely love it how clear it is.
- bzdzb 14y agoI agree. The alternative as you state is nested conditionals. Yuck! An alternative construct I have seen and used is to wrap code in a do {} unless(0) block and break to a single failure return or complete the block to a single success return.