It just depends on the complexity, relevance, and size
What's particularly good about both?
They end up only assigning val once, so after some further refactoring we may end up with the superior const binding!
F.A.Q:
Is early return at odds with functional programming?
Should we strive to use conditional expressions at every size?
No. Used correctly, return is just guards in a match expression. You could see it as advanced pattern matching that is missing from JS syntax.
(Early throw, on the other hand, is usually a hack we have to use for lack of static types.)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
If we know the branches will have
return
, then B, plainif
, aka early return is better.We don't need to keep the context of whose
else
we are in anymore most of the time.Even refactoring it is easier, both in terms of just editing the code and the resulting git diff.
However, if we don't have
return
......then there are two options for me.
1. Extract into function
2. Use a conditional expression
It just depends on the complexity, relevance, and size
What's particularly good about both?
They end up only assigning
val
once, so after some further refactoring we may end up with the superiorconst
binding!F.A.Q:
Is early return at odds with functional programming?
Should we strive to use conditional expressions at every size?
No. Used correctly, return is just guards in a match expression. You could see it as advanced pattern matching that is missing from JS syntax.
(Early throw, on the other hand, is usually a hack we have to use for lack of static types.)