JavaScript: jslint, data types, “null” and “undefined”

February 27, 2008 on 1:52 pm | In JavaScript |

Straight to the point: If you want to get one thing out of this article, get this:

In JavaScript, “null” is not the same as “undefined”.

This was what costed me some debug time recently when working with JavaScript at my job.  I will talk about how I came across this issue, because there are various valuable aspects of this story that could be worth reading for those of you frontend developers.

Actually, scratch that, if you don’t know about jslint, do read the following section too. It is useful, and you won’t regret it.

jslint

First of all, most of you know that JavaScript is a pretty loosely-enforced language.  Most browsers out there (IE, Firefox, etc.) are pretty tolerant to sloppy code, just like HTML. To be fair, it’s not the browsers’ faults completely, since in a lot of cases, JavaScript was defined to be like that. For example, it tolerates missing semi-colons at the end of a line. Nonetheless, JavaScript is very powerful, despite these problems that make programmmers cringe. Here’s a good read: JavaScript: The World’s Most Misunderstood Programming Language.

The problem comes when there are multiple browsers. Each can interpret things a little differently. With Firebug and Venkman, it’s easy to develop for Firefox and pinpoint errors. (I personally just use Firebug, in the short time I’ve tried Venkman, I found it too complicated.) For IE, this is a lot harder. The best free tool I’ve found is MS Script Debugger (free but requires genuine Windows ), possibly along with IE Developer Toolbar (completely free). IE Developer Toolbar is similar to Firebug, but without the JavaScript part. (only CSS and DOM inspecting)

With simple JavaScripts, debugging is usually not a problem. But when you get into object-oriented JavaScript, involving code spreaded out to many files, (IE’s internal-secret-line-numbering doesn’t help) it’s a nightmare. Couple this with the fact that IE has their own strange interpretation rules, you often cannot find where errors are happening.

Fortunately,  Douglas Crockford developed an extremely useful tool, called jslint. It’s even web-based (developed with JavaScript itself!), so you don’t have to install anything. All you do is copy and paste your JavaScript in there, and let it validate. Kind of like a w3c validator for HTML, also kind of like a compiler for C++. The lint program is/can be very strict on your code — this means if your code passes jslint, it is extremely likely that it will work fine in all browsers including IE.

Data types comparisons

In JavaScript, there are a few basic data types you’ll be using a lot, such as integers, strings, booleans. Because of the loosely-enforced nature of JavaScript, comparisons are made to be loose as well. To give an example of what I mean:

var mynum = 0;
var mybool = false;
if (mynum == false) // this evalutes to true
if (mybool == 0) // this evalutes to true

They are all the same in “value”. To further enforce your code logic to make sure you’re doing what you want to do, jslint recommends using === or !== to check for equalities/inequalities when one side involves zero, false, null, empty string, etc. The === or !== operators also check the data type. To give an example, continuing from above:

if (mynum === false) // this evalutes to false
if (mynum === 0) // this evalutes to true

Once you understand this part, let’s move on to the next section.

“null” and “undefined”

In JavaScript, they are different. Null is a value that is only assigned by a programmer. You can set a certain variable to the value null. Undefined is what a variable has if it wasn’t assigned to anything.

I had no idea about any of this before, so I googled it up and found this article: JavaScript Difference Between null and undefined. It has a clear and simple example to demonstrate the point. To be more specific about the kind of problems I ran into, we had something like this in our code.

myFunc = function(arg1, arg2, arg3) {
if (arg3 == null) {
// do something
}
};

This was working fine at first. If you call myFunc without arg3, it goes in the conditional statement and executes whatever is inside. When I ran the code through jslint, and changes the check to (arg3 === null) as it recommends, problems arose. It never went into that condition anymore and the bug travelled very far along the code to some weird behaviors. (because this function happened to be the constructor for a class in our case, making it hard to find at once)

I eventually realized that, when you don’t pass in arg3 to myFunc, arg3 then has the value “undefined”. The value, without the type, is the same as “null”. Initially, it worked fine when we only use ==. But when we add in type-checking, with ===, they are not the same. Thus, the code needed to be fixed to say:

if (arg3 === undefined)

Conclusion

It was a good lesson to me. Even though I’m coding up object-oriented JS left and right, there are still basics about the language that I admit I’m not familiar with. I learned something, and I hope you learned something out of this entry as well.