JavaScript Day 10: Tools, Part 1

I wanted to cover a few tools for JavaScript coding as we go through this series. Today’s is JSLint.

JSLint takes its name from an early program used by C programmers called “lint”. This tool searched through C source code, looking for suspicious code, stuff that might not wind up in a compiler error, but would probably cause some kind of problem somewhere down the line. These days, compilers pretty much take care of that themselves, with a rich set of configurable warnings. But JavaScript isn’t compiled. You can write it and put it up on the web as-is. It works or it doesn’t. It’d good code or its not. Thus, it’s a great idea to run it through something that will catch some stuff you might not.

JSLint is a program that analyzes your JavaScript code and reports back on what it finds. It has a whole load of options, so nobody’s telling you what standards you have to comply to, but of course, the more things you have it check for, the more robust your code is likely to be.

There are a few ways to use JSLint. One is to head over to JSLint.com, copy the code you want to check, paste it into the big text box, hit the button, and behold! If your code passes the first time without ever having checked it before, congratulations! Chances are, there will be several errors. Note, as this page tells you, “JSLint will hurt your feelings.” If you want a bit more info on why some of the things that are showing up as failures are considered bad, the aforementioned page will also explain that.

Note that failures show up in a pink box below the input box. Below that is a white box with info about the results of the scan. Stuff that shows up there is not a failure, just letting you know various things about your code, such as the variables in each method, any global variables you may have introduced, etc. It’s good to scan that stuff too, as even though it might not be a failure from JSLint’s viewpoint, there might be something there you didn’t intend.

Below all that is another box full of options. Note the “The Good Parts” button, which will select almost all the options in the first column. JSLint was created by Douglas Crockford, who is also the author of book by the name of JavaScript: The Good Parts. Presumably, the reason for these choices are explained more thoroughly in the book. (Shamelessly promoting his own book on his own site! The horror!) But a lot of these are explained as well in the page I just mentioned. The only one I really have a problem with is the strict whitespace one. Apparently “strict” includes spaces between if, for, function and the following parentheses, i.e. “if (foo)” instead of “if(foo)”. This seems far more of a personal preference than most of the other options, such as “disallow undefined variables”. But you don’t have to check it.

The next column includes a couple of very useful options, “Assume a browser” and “Assume console, alert, …” These will let you get away with the use of various identifiers that are not defined in your code, but would be defined in the browser environment. Stuff like setInterval and getInterval will also be controlled by this.

The last column is kind of the opposite of the first. Whereas the first column makes things a bit more strict than the default, this loosens some of the rules.

Below that are a few other options, most importantly the “predefined” field. Say we were to take any of the scripts we’ve been using with WireLibJS over the last week or so. They’d all fail, saying that neither “$” or “wirelib” is defined. Of course, in the context of a web page where the jQuery and WireLibJS libraries are both included, there’s no problem. But JLint doesn’t know about that web page or those other files. You need to tell it that those identifiers really do exist. Putting “wirelib,$” in the predefined field cleans that right up.

Integrating JSLint into your workflow

So all this is fine, but copying, pasting, reading line numbers of errors, fixing them, copying, pasting, again, can get pretty tedious. It would be better if we could do all that right from our editor. Well, in many cases you can. Some editors do have JSLint built right in. Others, such as Komodo Edit, have extensions available for this purpose. I’m using the kojslint plugin. You download this as an .xpi file, and open the file up directly with the file menu of Komodo Edit (took me a minute to figure that out). This should give you a JSLint item in your Tools menu. This will expand into Run and Options items.

Run will simply run JSLint on the currently open file, giving the results in a panel below. Now you can click on any error in the list and go right to that line of code. Way better!

Opening Options will bring up an options panel on the side. Here you have all the options from the web page, as well as a neat “Mode” dropdown. By default, it’s in “The Good Parts” mode. You can create your own modes, which are really just a collection of options. You can also add predefined identifiers, and run JSLint right from this panel. Run it, double click on the errors, fix them, run again till complete.

I’ve updated wirelib.js so it is fully compliant with The Good Parts (even the strict whitespace one, grrrr…). I even found an undefined variable in there. Shame.

This gives you a bit of a warm feeling, somewhat similar to doing good unit testing. It doesn’t mean your code is perfect, or even great, but if it’s lint free, you have at least some small sense of security that you are at least covered on the major bases.