JavaScript without if else cascades


Never ending JavaScript. 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? An 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.

if() expression returns a value
you are by now not a beginner and you confidently
write this kind of 'advanced' JavaScript 
var x = if ( a ) "A" ;
else if ( b ) "B" ;
else if ( c || d ) "CD" ;
else "E" ;
X is what here?

Above we give x its value as the result of 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.

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. Some will simply mandate the switch statement instead of if else cascades. If they can replace them cascades with 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 starts 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.

And solution to the above problem is coming next.

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

dbj.cond()  will also take arrays (if given as arguments) and look inside them for comparison . Which 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.

use key.which with dbj.cond() for handling the key typed 
dbj.cond( key.which,
/* if key is in here */[10 , 13 , 32 , 34 , 39, 40],
/* return the following function */
function () { go('next'); },
/* if key is in here */[33 , 37 , 38 , 8],
/* return the following function */
function () { go('prev'); },
/*if key is 36 */ 
/* return the following function */
function () { go(0); },
/* if key is 35 */
/* return the following function */
function () { go(slideCount - 1); },
/* if key is 67 */
/* return the following null function */
function () { },
/* if key is 79 */
/* return the following function */
function () { $('.outline').toggle(); },
/* otherwise return a null function */
function () { }
on the line above we immediately call 
the function returned
spot the () above

Above is also and in 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 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 ‘lamdas’) 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 form LISP (cond …). But then JavaScript 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.