Tag Archives: evaluation

Abusages in JavaScript

Upon reading a recent blog entry by Brendan Eich (creator of the JavaScript language), I found myself falling under a bit of conviction when he described a popular use of || (OR) and && (AND) as an “abusage”.

I also agree…that the && line (!isActive && $parent.toggleClass(‘open’)) is an abusage, allowed due to JS’s C heritage by way of Java, but frowned upon by most JS hackers; and that an if statement would be much better style.

Now this word hardly requires defining for most of us, but for everybody else it is described on Wictionary as improper or incorrect use of language.

If you’re not familiar with using || and && in the aforementioned manner, here’s the reasoning behind it. It acts as something of a short-cut if-statement. In fact, as Brendan said “an if statement would be much better style.” Let’s compare the two:

!isActive && $parent.toggleClass( 'open' )

In this line, if everything to the left of the operator evaluates to true, the “argument” to the right is also evaluated. Of course this behavior is being tricked into actually executing a method if the argument to the left, treated as a condition all by itself, evaluates to true. As an if statement it would look like this:

if ( !isActive ) $parent.toggleClass( 'open' )

This makes sense to the majority of developers. It actually reads the way in which we expect it to behave.

Similar to the if statement, if our “condition” (in this case, everything to the left of &&) evaluates to false, only then will the statement on the right be evaluated, invoking the toggleClass method.

The && and || operators perform what is known as short-circuit evalutation. The second argument is only evaluated if the first wasn’t sufficient to determine the value of the expression. Contrary to &&, || will only evaluate the argument to the right if the argument on the left evaluates to false.

I really only learned about this trick of the JavaScript language in the last year or so. I have been using && and || in expressions for years, but never thought to bring them outside the parens.

Lately I have been using these within things like feature-detection:

!!foo.classList || loadScript( 'classListPolyfill.js' );

Using double-negation (!!), we can convert an undefined value into a boolean false. So if the classList member is not found, the argument on the left evaluates to false, which in turn causes the “argument” on the right to be executed. We hi-jack this behavior to load a polyfill script for the classList member. You could modify this to use && instead, and save a char, however “OR” sounds more appropriate.

Bottom line, if Brendan Eich is right (and I suspect he of all people would be), it’s far wiser to just stick within the design and intended use of the language:

if ( !foo.classList ) {
  loadScript( 'classListPolyfill.js' );

There goes another super-cool esoteric trick of the masters. Guess I’ll find my seat on the bench and wait to be picked for dodge-ball.