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

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

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

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

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

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.