Enforce coding standards with JSHint

Learn how to use JSHint to enforce your coding standard. Tony Patton says JSHint is the only tool he uses for his JavaScript projects.

JavaScript is no longer seen as a scripting language for web designers -- it is now accepted as a full-fledged language. With that label comes all of the expectations about languages that developers have had for years. One expectation about coding standards is: The general guideline is code does its job well, while being easy to maintain and understand by developers who may have to work with it in the future. There are no global coding standards for JavaScript, but organizations and projects adopt their own. Here's an examination of how to enforce a coding standard with the JSHint linter tool.

What is a linter?

It's incredibly frustrating to be tasked with making changes to an existing application with code that gives you headaches. While coding standards can’t make everything crystal clear, they can lend some familiarity and organization to code that will make it easier to navigate and understand.

A linter is a tool used to find problems or possible issues in code. There are many such tools for JavaScript, but JSHint is the one I use for all of my JavaScript code/projects.

Getting JSHint

You may think of JSLint (as I did) when confronted with JSHint. The two are related -- JSHint grew of the JSLint project (the JSHint crew wanted more features). A key feature of JSHint is its flexibility. You can take it for a test drive on its home page, where they provide a real-time interface; you just enter your code and click the Lint button. There are various options available at the bottom of the page via checkboxes. Another way to utilize JSHint is to install it locally via Node (with NPM). Once installed locally, you can use the JSHint command-line interface while passing in your JavaScript source file(s). The documentation covers everything you need to use it.

Once JSHint is installed, the key is to find and use the correct options to meet the needs of your organization or project. The online help provides great information on the options available. You can specify JSHint options directly in code with the JavaScript comment syntax, but the preferred method is to use a separate configuration file, which defines the options that correspond to your needs.

The basic format of the configuration file is the JSHint option in quotes separated from its value with a colon. Multiple lines are separated by a comma ,with the entire file enclosed in curly braces. The following snippet shows a basic configuration file with comments to explain what each line does.

"debug": false, // Allow debugger statements like browser breakpoints
"devel": false, // Allow development statements like console.log()
"newcap" : true, // Require capitalization of all constructor functions
"indent" : 2 // Specify indentation spacing

This configuration file (saved as test.config) could be applied to a JavaScript file (called test.js) with the command-line using the following syntax.

jshint -config test.config test.js

The JSHint options available are interesting to review. Two that caught my eye are maxlen, which allows you to specify maximum line length, and maxdepth, which defines how nested blocks should be.  

You can also utilize JSHint within your JavaScript by referencing its library. The online documentation provides more information on this approach, as well as the previously discussed options. The best approach to using and enforcing standards via JSHint is to integrate it into your build process or the preferred developer IDE.

The JSHint installation directions include a great deal of information on utilizing it within your favorite IDE. These are outlined in the Plugins section, with a wide variety of editors supported. (The Visual Studio Web Essentials extension includes JSHint, which means it will automatically run within that environment -- the JSHint configuration options are accessible in the IDE.)

The final tidbit from the JSHint documentation is the links to related tools and "cool stuff" on the install page. The FixMyJS tool, which piggybacks on JSHint with the intent to automatically fix mistakes like missing semicolons, caught my eye. I’ll have to play with FixMyJs more to get a better feel for whether it actually is useful.

Don't go overboard

I know some developers and managers who have gone overboard with the coding standard approach, and they made the their developers' lives miserable. It is nice for all developers to use the same notation and layout for code, but you should not lose sight of the main goal, which is code that does what it is supposed to do.

Development is a creative profession, so use standards to guide coding as opposed to stymying creativity. When you know what standard you want, you should use JSHint to ensure code follows your guidelines.