JavaScript without if else cascades

[2021 APR 29]

Alive and kicking on the NPM.

Just refreshed it on GitHub too. Documentation is a bit more clear now.

I think it is very likely it will be done in TypeScript too.

[2017 JUL 27]

Is this a rehash of an old post? Yes, it is.
But is it still relevant.? Well, yes it is. Very much so.

Please (re) read carefully and try and use in your production JavaScript.  In case you want it to be resilient and efficient JavaScript.

[first published 2011 Sep 15]

So you are proficient in JavaScript.  Perhaps a wizard? A beginner? A JavaScript Ninja maybe? Awesome.  Question for you. Do you enjoy writing longer if else cascades? Or the long ones?

Never mind that (for a moment) now admit to yourself, how many times in your ninja turtle life have you written this kind of JavaScript code.

Above we give x its value as the result of an if-else cascade. We can try and wax cynically on the philosophical cons and pros of the above code. Some of you, I am sure will immediately label this example as an “obfuscation”, which can be nicer coded with the ternary ? :  operator. True. Maybe.

But only to a certain level of complexity. While more imaginative, or should we say better, coders will see the potential for some serious silent bugs and will suggest some clever if-else coding idioms (like “lookup table”). Some will simply mandate the switch statement instead of if-else cascades. If they can replace them cascades with a switch, that is.

But inevitably, code changes and grows, and very soon none of us are satisfied with the ever-growing amount of very carefully placed if’s and else’s. At this point, 99% of coders will simply persevere through these ever longer if else cascades. Test, debug, test, etc until it works. And then leave it for somebody else to worry about in the future.

But I am not satisfied with this. I do not like code sprinkled with time bombs. Every medium complexity if else cascades start shaping up as a potential source of future trouble. Not to mention the long ones. Or really (really) long ones. This is not resilient programming. Or scalable.

Every IF-THEN-ELSE might grow into a source of serious trouble

And the solution to the above problem is coming next.

We will use another real-life example at the same time: Handling the key, the user has typed.

dbj.cond()  will also take arrays (if given as arguments) and look inside them for comparison. This is also yet another advantage vs the standard if() statement. Here is dbj.cond() way of coding.

Including the solution with lambdas as arguments, of course.

(Above is also and at the same time a nice little function dispatcher.)

Now, this surely would be more difficult with standard if-else-if-else cascading. For 90% of the JavaScript population much more difficult and error-prone actually. And there is something more “hidden” above. The solution to the problem of “expressions as arguments”.

Look carefully. Above we do not execute anything given as arguments. We simply put the code in anonymous functions (aka ‘lambdas’) and return one of them. And then the function returned we simply call upon returning it from dbj.cond().  This is a way to avoid the execution of any of the code given as arguments to the dbj.cond().

So. As complexity grows dbj.cond() becomes more and more useful. And vice versa. And who can guarantee that any of the production code will not grow in complexity?

I admit, I nicked the concept from LISP (cond ...). But then JavaScript’s power of expression did the rest of the magic.



This is where dbj.cond() resides.

Use dbj.cond() for clean but complex logic coding, but by no means do not get carried away with your “discoveries” and inventions of some clever usage patterns of yours. Keep it simple.

One thought on “JavaScript without if else cascades”

Comments are closed.