4 ms·
It definitely depends, but personally I find early returns to be a bit of an antipattern IF they're based on business logic. If a function has lots of ifs, you
by fenomas 2y ago
It definitely depends, but personally I find early returns to be a bit of an antipattern IF they're based on business logic. If a function has lots of ifs, you can glance at the nesting to see which ones affect the line you want to edit, and ignore the others. But if the function has lots of returns, you have to check every one before a given line in order to know what constraints are true at that point.
OTOH early returns are great for anything the type checker knows about:
function foo(msg: 'OK' | 'ERR') {
// ...
if (msg === 'ERR') return someValue
// ...
}
Doing that is hugely cleaner than branching, and there's no added complexity to the developer since tooling can easily tell you what values `msg` can have at any given point in the function.
- jonathanlydall 2y agoCalling it an anti pattern (as opposed to a subjective preference) is in my opinion super dangerous and reeks of cargo-culting as it implies an active avoidance of it which can result in deep nesting or contorted and hard to read logic. There is no hard rule about early returns being always good or always bad, it depends on the particular situation.
- deleted 2y ago[deleted]
- fenomas 2y ago> > It definitely depends, but personally I find.. > ..(as opposed to a subjective preference) is in my opinion super dangerous and reeks of cargo-culting.. o_O
- kazinator 2y ago> you can glance at the nesting to see which ones affect the line you want to edit, and ignore the others. Only if all the cases return! Only then is it obvious that you have independent cases. E.g. suppose we have three Boolean inputs x, y, z and want to do something for each binary combination: if (x) { if (y) { if (z) { return 7; } else { return 6; } } else { // x && !y if (z) { return 5; } else { return 4; } } } else { // !x if (y) { // !x && y if (z) { return 3; } else { return 2; } } else { // !x && !y if (z) { return 1; } else { return 0; } } } How would this look with early returns? One obvious way: if (x && y && z) return 7; if (x && y && !z) return 6; if (x && !y && z) return 5; // ... etc (Let's ignore that we can just calculate the output with some bit twiddling; that's not the point). Early return can be very clear, if we can bear repeatedly testing some conditions.
- fenomas 2y ago> Only if all the cases return! My comment was about using if blocks as opposed to early returns. I.e. where the nested ifs run exhaustively and return afterwards. Also, obviously deep nested ifs aren't good, so I wasn't advocating them - I just think it's better to fix them by splitting functions or simplifying control flow, than by adding early returns.
- kazinator 2y agoSo it is more about multiple returns, versus setting some local return variable and returning in one place. However, setting that return variable can be recognized as a simulated return. If we know that after "ret = 42", there are no other state changes; that the whole if/else mess will drop out to the end where there is a "return ret", then we can just read it as "return 42".
- fenomas 2y agoSure, in the narrow case where the function only calculates a single return value and has no side effects.