Content
@
https://opensea.io/collection/dev-21
0 reply
0 recast
2 reactions
greg
@gregfromstl
Potentially hot take but early returns are horrible for readability and should be avoided https://x.com/t3dotgg/status/1799640178459656662?s=46
3 replies
0 recast
12 reactions
Jax
@jaxer.eth
Def a hot take
1 reply
0 recast
1 reaction
greg
@gregfromstl
Why? If there’s an opportunity for an early return there’s probably an opportunity to break down the function into smaller ones
1 reply
0 recast
0 reaction
Jax
@jaxer.eth
Yeah fs, but breaking it down further to avoid early returns makes it harder to read and parse imo I can get behind no early returns for other languages (particularly functional ones), but I like being able to immediately ‘throw out’ error cases with early returns in js Gimme pattern matching and this changes…
2 replies
0 recast
0 reaction
greg
@gregfromstl
But throwing out error case should throw an error, right? By early return I mean a non-error value
1 reply
0 recast
0 reaction
Jax
@jaxer.eth
Throwing instead of early returns in some cases is probably more 'correct', but I usually prefer early nullish returns so typescript will bake the 'error' case into the function signature But even for non-error early return values I've never found them hard to read, that's more personal preference though
1 reply
0 recast
0 reaction
greg
@gregfromstl
“so typescript will bake the error case into the function signature”: check out neverthrow
0 reply
0 recast
0 reaction