if(i < 0) {
  //something
}
else if(i == 0) {
  //something else
}
else {  //use as default
  window.dump('i is strictly superior to 0, since i = ' + i);
}

I often use this in the same conditions as a switch but when I know that the first conditions are more likely to happen.

there is very good reasons when to use switch-case:
– when performance is an issue
– when each token i distinct (or nearly)
– when the context matters
– when other people read your code (as stated by Antonio)

i’ve used switch-case when formulating my code-parser in this way (which is the fastest and best way to do so)

var tokens = [
	'distinct1','distinct2','distinct3',
	'mixed1','mixed2',
	'various','undefined','crap'
]
 
var context = "";
 
for(var i=0,token; (token=tokens[i]); i++) //unsafe code !!
{
	switch(token)
	{
		case 'distinct1': context = do1(); break;
		case 'distinct2': context = do2(); break;
		case 'distinct3': context = do3(); break;
		case 'mixed1':
		case 'mixed2': context = doMix(); break;
		default:
			if(token == 'various'){
				context = doVar();
			}else if(token == 'undefined'){
				context = doUndef();
			}else if(token == 'crap'){
				context = doCrap();
			}else{
				//somethingElse()
			}
			break;
	}
}

which performs REALLY good, and carries the context throughout the switch selector…

ofcause you could upgrade the lookup to take the context on call:

 
function doX(context){ return context; }
function doY(context){ return context; }
function doN(context){ return context; }
 
var cases = {
    1: doX,
    2: doY,
    3: doN
};
 
if (cases[something]) {
    context = cases[something](context);
}

but wouldn’t perform as good as the switch-case because of the copy of context in each call..

function cond( v ) {
  var i;
  for (i=1 ; i < arguments.length-1; i+=2 ) {
  	var vals = typeof arguments[i] == "object" ? arguments[i] : [arguments[i]];
	for (var j = 0; j<vals.length; j++)
	  if (v===vals[j]) 
	    return arguments[i + 1];
  }
  return arguments[i];
}

Fallthrough could now be emulated giving an array for some values:

cond(x,2,"green",[3,4,5],"yellow","defaultclr");

And kzz conditional bit could be done like so:

cond(true,x<2,"green",x<7,"red","defaultclr");

Finally, James’ original function lookup example (although missing the defined check):

cond(something,1,doX,2,doY,3,doN)();

Quite cute, I think! Although, as DBJ writes in his article, the actual value is obviously debatable.

…argh, sorry about the messed-up > and < ! James, help, how do I prevent that?

I think you might find this an interesting angle on the same theme …

–DBJ

A popular example is probably “toString”/”valueOf” keys which, when accessed on a plain object, resolve to `Object.prototype.toString/valueOf` respectively. Keys, matching other `Object.prototype.*` properties (either built-in or user-defined) have similar outcome.

Explicitly modifying keys before property access usually solves this “problem” nicely, albeit in expense of additional overhead. Other solutions, such as `hasOwnProperty`, are either not widely supported (e.g. Safari 2 lacks it) or are not reliable (e.g. `hasOwnProperty(‘__proto__’)` is `true` on plain objects in Gecko-based browsers).

Plus, web programming cannot really be prepared to any other type of programming (like “Real time airplane safety”). The basic principles may still hold true but there is a much higher demand for code customization on the web. Storing conditions extends this principle; it allows you and other contributors to change/debug conditions without having to go digging through the source looking through line after line of cases.

Speed/performance, especially when operating at such a high abstraction layer, is largely moot. I understand that we still need to take these things into consideration but today, right now, I consider readability and general code maintainability to be a much higher priority. The question of whether the syntax is cleaner is subjective and therefore really isn’t worth mentioning.

@unscriptable, another way:

var focusMethod = {
    1: function(){ input1.focus(); },
    2: function(){ input2.focus(); },
    3: function(){ input3.focus(); }
};

Multiple return paths may annoy you, but this is even worse IMO:

function something() {
 
    var retValue;
 
    if (true) {
        retValue = 123;
    } else {
        if (true) {
            retValue = 567;
        } else {
            retValue = 234;
        }
    }
 
    return retValue;
}

I know, I know, it’s subjective, but I just really hate this… It looks like the author wanted to follow the “single entry, single exit” rule regardless of what was practical. What’s so bad about multiple return paths anyway? – sure, over-usage is ugly, but if used wisely it’s not that bad IMO.