A Quick Tour of Douglas Crockford’s JSLint

12/21/12

JSLint is a code quality tool for JavaScript developed by Douglas Crockford. He’s a senior JavaScript architect at PayPal and writer that helped popularize JavaScript Object Notation (JSON), among other things. Originally released in 2002, Crockford modeled JSLint on lint, an old C utility for catching common programming errors that were not detected by compilers. Like Lint, it scans source code looking for potential problems, and reports them in an all-inclusive list or on an item-by-item basis. Those unfamiliar with the tool tend to find a lot of the error messages a little on the cryptic side. The options can be equally intimidating to the uninitiated. For those reasons, some familiarization should be in order. In today’s article, we’ll get ourselves better acquainted with some of JSLint’s most important options and rules.

Submitting the Source Code

To put JSLint through its paces, I chose to submit the main script file for my fun little Stock Strategies Simulator Web app. Considering the amount of code and JS libraries involved, I figured that it was bound to produce a lot of messages. I was not disappointed!

Although a number of plugins have been developed for JSLint (more on that later), the main app resides on the Web. A huge source code textarea, a button, and options are all conveniently laid out on one page. There is no upload feature, so you have to copy and paste the code into the textarea – easy enough.

Despite the size of the file (1300 lines), the analysis completed in well under a second and produced a list of dozens of infractions. Yay!(?)

Interpreting the Results: Why Does JSLint Shout at Me?

The first item that the utility took offense with was an enumeration of dollar cost averaging schedule constants:

var DCA_SCHEDULE = {
  UseDeviationThreshold: 0,
  Weekly:                1,
  BiWeekly:              2,
  Monthly:               3,
  BiMonthly:             4,
  EveryThreeMonths:      5,
  EveryFourMonths:       6,
  EverySixMonths:        7,
  Yearly:                8 
};

The exact error list I received (with a few lines omitted) was:

  UseDeviationThreshold: 0,

  Weekly:                1,

  BiWeekly:              2,

  Monthly:               3,

[lines omitted for brevity]

  Yearly:                8 

};

JSLint contains a number of rules pertaining to the style, appearance and formatting of JavaScript code. This includes stipulations about bracing positions, indentation and spacing. The idea is that legible code equates to more maintainable code, which itself results in less ambiguity and fewer bugs. Moreover, believe it or not, sometimes formatting and positioning does have functional implication as well, and can lead to bugs. However, in this instance, it’s just a simple case of incorrect indentation.

If you wish, you can click the blue button beside the (Tolerate…) “messy white space” Options item. That will set it to true, causing JSLint to ignore indentations.

The ‘Ole “{A} was used before it was defined” Error

Another common error, which I received was:

'jQuery' was used before it was defined.

jQuery('#useDeviationThreshold').bind( 'change', function(evt) {

The cause of this error was a simple one; JSLint expects all variables to be declared using the “var” keyword or within a function signature. It doesn’t know anything about jQuery, so it flags it as being undeclared. The same thing would have happened with the dollar sign ($) jQuery abbreviation.

Since you wouldn’t want to redeclare a global JS library reference, you can add it to the “predefined global variables” list in the textarea at the bottom of the Options section.

Missing Use Strict Statement

Moving right along, I encountered the oft-seen-yet-enigmatic “Missing ‘use strict’ statement” error for the following line:

var select = jQuery('#DcaInterval')[0];

To be perfectly honest, I’d never heard of this statement before! It turns out that the “use strict” directive is part of the ECMAScript 5 specification. It can be placed at the top of your scripts or as the first line in a function to force the engine to conform to a strict subset of the language. While it’s not yet supported by all of the major browsers, it doesn’t hurt to get ahead of the curve on this one. JSLint will throw the “Missing ‘use strict’ statement” error when it encounters any function (or whose ancestor scopes) that does not contain the strict mode directive.

There’s an option item to tolerate the “missing ‘use strict’ pragma”, in case you want to get rid of those errors.

Displaying One Error At a Time

Should you find the list of errors too much to deal with, you can have JSLint stop after one error has been found by turning on the “Stop on first error” setting.

The jslint4java Plugin

One last thing, there’s a java wrapper for the JSLint tool called jslint4java that you may be interested in. It can be integrated into an IDE such as Eclipse or you can use the ant task to run JSLint as part of your builds. To install it in Eclipse:

1. Download the jslint4java.jar file from the jslint4java site.
2. Add an external tool configuration in Eclipse (Run > External Tools > External Tools Configurations > Program > New…):
   Location: /usr/bin/java (or your path to javaw.exe), Arguments: -jar /path/to/jslint4java.jar ${resource_loc}

Once installed, select a .js file in the Project Explorer and run jslint4java from the external tools menu to analyze the code.

We’ll delve deeper into the wondrous world of JSLint errors and options in an up-coming instalment.