Re:Using the switch(true) pattern in JavaScript
by brundolf on Monday April 12, 2021 @03:33PM
(#26784050)
The problem is definitely much worse when returns are scattered throughout the function instead of grouped at the top, but I still prefer them to be "elsed" together (or in a switch/cond/match statement or whatever). Worth noting that in Lisp - one of the classical languages where early-returning is popular - there isn't a problem because it is done as I describe:
(cond
(early-return-condition early-value)
(second-early-condition early-value2)
...
(t final-else-value))
The "default case" is on the same footing as the other cases. Only in procedural languages does the control-flow get confusing if you aren't careful.
Re:Using the switch(true) pattern in JavaScript
by t-writescode on Monday April 12, 2021 @03:35PM
(#26784078)
If you want elses everywhere, how do you protect yourself from nesting hell? I find nesting hell to be far, far, faaaar worse for readability than any of the alternatives, and will move to the early return model to escape all that nesting.
Re:Using the switch(true) pattern in JavaScript
by brundolf on Monday April 12, 2021 @03:41PM
(#26784157)
I dunno, I just rarely ever find myself nesting more than two or three levels of conditionals even in extreme cases. If my logic really is that complicated, it's probably a sign it needs to be broken up anyway. And if I did need that much branching, I would want to be more explicit about it, not less.
Also - at the very least - you can mimick the "flat" early-return style and just stick some else's in there and call it a day. That's my main point; less so the actual deeper nesting
If people tend to write:
Then the shape of the code and the "pattern" of early returns gets broken.If you read code where all of the short-circuit, early-return logic is at the start of the function, and then all of the work is done, do you still have this opinion?
E.g.