JSHint, A JavaScript Code Quality Tool

Funny they should say that. An extra comma can take down multiple versions of IE, and is something tools like JSHint can easily catch. I can't think of a good reason not to use JSHint to catch stupid mistakes we all make.

John Carmack wrote a great blog post a while back about Static Code Analysis.

http://altdevblogaday.com/2011/12/24/static-code-analysis/

While not all of this is immediately applicable to JSHint and the like, it provides some insight into why static code analysis can be seen as helpful.

As you also mention, it's really helpful for code within a codebase to be consistently written. JSHint can help enforce some of that consistency. This is where JSHint really shines.

If your JS is tied to some sort of "build" process (even a short 1-2 second one), catching errors before running the build is incredibly helpful. If you intend to minify your JS code (as you should) before distribution, finding missing semicolons can be very important, indeed. I find the most helpful JSHint errors to be about mistyped variable names. It's so much easier to see that in my editor, fix it, and THEN run it in the browser.

I used to have this problem, now I just wait until the missing semicolon costs someone a day of debugging or a broken deploy.

Funny, a missing semicolon was what convinced us to start lint-checking all our JS.

We have a Rails app with multiple JS files. One of them ended with a statement like var foo = { /* object contents / } / no semicolon here */

This worked in development but broke in production. Browsers seemed happy to assume the missing semicolon when the closing brace was followed by the end of the file. But in production, this JS file had other files concatenated to it, and it broke.

Lesson learned. We now use Syntastic to check our syntax in Vim, including Javascript.

JS static analysis tools can help you find mistakes that are often more serious than a missing semicolon.

I've run into something like this before:

  for (var i = 0, len = items.length; i < len; i++)
  {
    var item = items[i];
    // ...maybe some more code here...
    var subItems = item.subItems;
    for (var i = 0, len = subItems.length; i < len; i++) {
      // whoops
    }
  }

The inner for loop's i & len variables are really the same as the outer for loop's i & len variables (there's no shadowing going on here because they're all in the same scope in JS). Depending on the order of things and how many subItems there are, you could end up with an infinite loop, iterating over the same items multiple times, or skipping certain items. It seems like it'd be an obvious problem to see, but if there's a significant amount of code above the inner for loop, you might miss it. It also seems like it'd result in very obvious bugs, but if subItems are rare, most of the time this code will run just fine.

Most of the JS static analysis tools will complain about redeclaring i and len, which makes spotting this kind of problem much easier.

You might check out Syntastic. It supports JSHint if you have it installed and also supports other languages. I switched to it after using the JSHint plugin for a while.

https://github.com/scrooloose/syntastic

Ideally, you won't be using the web interface, but running the command line utility version.

My company recently implemented this as part of a git pre-commit hook so that we're less likely to have a silly syntax mistake cause problems.