Javascript Madness: Treacherous Type Conversions

One of the most frequent sources of Javascript bugs for me is the way type conversions between strings and numbers work. This page exists to allow me to vent my annoyance on the subject, and perhaps to help put other programmers on guard.

In Javascript, as in most any other programming language, 1776 and '1776' are two very different creatures. The first is a number, the second is a character string.

In some languages you can only convert from one to the other by an explicit conversion. For example, in C, you convert a string to a number with atoi("1776") or a number to a string with sprintf(buf,"%d",1776). Furthermore, all variables are typed. You declare whether they will hold strings or numbers at the time they are created.

Other languages, like Perl, are much more liberal. The same variable can hold either a string or a number, and it hardly ever matters which one it does contain. If an operation calls for a number and one of it's arguments happens to be the string '1776', then it quietly converts it to the number 1776. Thus you hardly every have to worry about which of the two representations of a number is actually stored in a variable. (Though you do have to deal with the fact that you have two different comparison operators, == and eq, one that converts its arguments to numbers before comparing, and one that converts them to strings before comparing.)

Javascript, like Perl, allows variables to store any type of data, and does a lot of automatic type conversions between strings and numbers, but the automatic type conversions don't give you the total coverage that they do in Perl. If your variable contains '1776' instead of 1776, most operations will treat it just like a number, but a few won't. Thus, instead of causing immediate problems as it would in C, or running along just fine, as it would in Perl, it goes along for a while and then starts doing weird and unexpected things.

These kinds of bugs are hard to find, and they happen a lot, because pretty much any way you read a number into a program gives you the string representation of the number. The best practice is to always immediately convert all numeric data into actual numeric variables as soon as you read them in, but it is very easy to miss this and have string representations of numbers slip into your program, where they may or may not eventually wreck havoc.

Additive Overload

This business of having the same operator do different things depending on the types of the operands is called "overloading". It was a moderately good idea in languages like C++ with strongly typed variables. When you typed '+' sign in C++ you pretty much always knew what it was going to be doing, because you knew the types of the variables that were being added.

But in Javascript, the variable types are unknown until run time. So, though you may know what you want your plus operators to be doing when you type them, what they actually do is up in the air until run time. Pass it the wrong type, and you are in for a surprise.

Here we have a little function that adds up n elements of the a array, starting with the element first:

    function sumSome(a, first, n)
    {
	var sum = 0;
	for (var i = first; i < first+n; i++)
	     sum += a[i];
	return sum;
    }

The problem is that the first+n addition in the loop condition becomes a concatination instead of an addition if either first or n is a string, so the upper bound of the loop becomes '23' instead of 5. But the < operator doesn't care. It happily converts the string '23' to a number 23 and does its comparison.

Note that here the < operator, which helpfully does type conversions, actually compounds the problem. The plus operator gave us a string instead of a number, but the < operator, instead of choking on it, merrily turns it back into a number and runs with it, so instead of a nice error message, we get wacky behavior which is much harder to debug.

This overloading of the plus operator is not entirely without theoretical advantages. For example, I could do this:

    string= sumSome(['a', 'b', 'c', 'd', 'e'], 2, 3);

Here's another oddity. Suppose you have this line of code:

   alert( nTopShelf + nBottomShelf + ' bottles of beer on the wall' );

   alert('Bottles of Beer on Wall: ' + nTopShelf + nBottomShelf );

Subtraction doesn't suffer from this problem. In fact, subtraction is the standard way of converting strings to numbers. So the following isn't the no-op it appears to be:

    size = size – 0;

    size = size + 0;

The switch Switcheroo

    if (hokeypokey == 0)
	putYourLeftFootIn();
    else if (hokeypokey == 1)
	putYourLeftFootOut();
    else
	shakeItAllAbout();

    switch (hokeypokey)
    {
    case 0:
	putYourLeftFootIn();
	break;
    case 1:
	putYourLeftFootOut();
	break;
    default:
	shakeItAllAbout();
	break;
    }

Here again, the type of a variable, which often doesn't matter because of the automatic type conversions, suddenly does matter. And once again, it's really questionable whether this behavior is ever really useful. Can you imagine ever writing a switch statement where you had different cases that did different things for the the string '0' and the number 0? If you ran across a program that did that, wouldn't you want to strangle the author?

Conclusions

So if you are programming in Javascript you are just stuck with these issues. The only thing you can do is program defensively. Try to remember to subtract zero from any numbers you read in. Probably library functions intended for broad use should subtract zero from any arguments that are expected to be numbers (and maybe throw an exception if the result is NaN).