How to improve code quality with JSHint?

Why it’s worth to know who uses JSHint?

Over the years JSHint earned the trust of the wide range of developers. On the official site of the project authors boast that their tools are used by such brands as Mozilla, Wikipedia, Facebook, Twitter, Bootsrap, jQuery… and that’s only the tip of the iceberg. After searching .jshintrc on GitHub we receive almost 340 thousands results!

Why is it so important? Mind that many of aforementioned projects are open-source. If you still don’t understand it, let me explain it now. Open-source means it’s available to view for everyone, and that possibility allows to check the configuration of JSHint. Now you get it? It gives the access to the huge number of ready configurations - is there anything better than learning from the best?

What JSHint won’t do for us?

JSHint is a powerful tool, but even it has some limitations. The static analysis of the code doesn’t allow to verify the correctness of the program, its speed or issues regarding memory leaks. Please remember that JSHint is only one of the elements of the process of ensuring high quality of the code. Functional and unit tests as well as code reviews are a good supplement for JSHint.

Installation of JSHint

Every release of JSHint is available via npm (node package manager) and all we need in order to install it is a single command:

npm install -g jshint

After that we can validate JavaScript files from the command prompt in any location (thanks to –g flag, which installs our tool globally).

JSHint is often installed locally in the desired location in the project what makes him added to the package.json file. In order to install it locally we have to type a command:

npm install --save-dev jshint

It’s very convenient to install JSHint as the extension to the selected editor. The most popular editors already features ready packages, which can be installed in simple and fast way. It’s the option, which, in my opinion, improves the work. I won’t describe the whole process here as it varies depending on the editor, but I highly recommend checking the official site of the tool.

If we’re using Grunt or Gulp, we can also use a plug-in which will automate our work with JSHint. The installation and configuration of such plug-in takes some time, but it's worth to do it. Details of the installation of selected plug-ins can be found here:.

• grunt-contrib-jshint for Grunt

• gulp-jshint for Gulp

This screenshot below presents examples of errors returned by Atom editor after installing linter and linter-jshint packages. JSHint informs us about the type of the error, the line where we can find it and returns the error message.

Configuration of JSHint

There are 3 ways of configuring JSHint:

• via --config flag
• via .jshintrc file
• via package.json file in jshintConfig

Using .jshintrc configuration file is the most convenient and we will focus on that.

It’s important to understand in what way JSHint searches for the configuration file. Firstly it checks the location where the validated file is stored. If the configuration file isn’t found, the program moves one level higher in the folders’ structure and searches for the mentioned file again. This activity happens till JSHint finds the configuration file or reaches the main folder of the project. It’s a good practice to store the configuration file in the main folder of the project.

Below you can find the description of a few configuration options selected by me.

Configuration - selected options

There are hundreds of possibilities in which JSHint can be configured. All of them have their detailed description in the documentation of the project. In this article I’ll explain these which are used by me and I believe are worth mentioning.

• browser: true – predefines global variables used by modern browsers, such as document, navigator, FileReader and more
• browserify: true – predefines global variables used by Browserify.
• devel: true – predefines global variables used in simple debugging of the code, like: console, alert and more.
• jquery: true – predefines global variables used by jQuery.
• curly: true – forces usage of curly braces even in case of block instructions which have only one expression. Even though JavaScript allows to omit these braces, it often leads to misunderstandings and, in consequence, errors.
• eqeqeq: true – forces using “===” instead of “==” and “!==” instead of “!=”. It’s a good practice which is worth using in order to avoid surprising results.
• eqnull: true – JSHint shows errors by default when we compare something to null. This options allows to compare to null which is really useful when we want to check whether the variable is equal to null or undefined.
• maxdepth: 3 – defines the maximum level of code nesting. It’s related to the readability of the code and multinesting should be avoided.
• undef: true – this option forbids using variables which weren’t previously defined. It’s really useful for finding typos in the variables’ names.
• unused: true – finds defined variables which aren’t used at all. Helps in keeping the code clean.
• plusplus: true – JSHint shows the warning about using “++” (incrementation) or “--” (decrementation) by default. Although it’s not a mistake, many developers believe that such a notation negatively affects the quality of the code and causes errors. Since I don’t belong to this group of developers, I have these operators allowed.
• quotemark: single – forces using single apostrophes in the whole code. This option is beneficial for the quality of the code.

Exemplary configuration file

Let’s take a look at the example of the configuration file, which would’ve been created if we have merged all these options.

{
"browser": true,
"browserify": true,
"devel": true,
"jquery": true,

"curly": true,
"eqeqeq": true,
"eqnull": true,
"maxdepth": 3,
"undef": true,
"unused": true,
"plusplus": true,
"quotmark": "single"
}

Validation of the code from the command prompt/console

Although it’s not the most convenient way, you should know how to refer to JSHint via command prompt or console. In order to do it, you have to type:

jshint --config=config.json myfile.js

--config flag has to be replaced with the location of the configuration file. The last parameter this command takes is the location of the file we want to validate.

As a result of the validation we can, for instance, receive:

myfile.js: line 10, col 39, Octal literals are not allowed in strict mode

Should you use JSHint?

If you value your time and nerves, there’s only one answer to that – yes, you should. Finding the error omitted during the coding can take hours of debugging.

If you’re working as a team of a few people on the same project, there’s only one answer to that – yes, you should. Forcing some rules of coding will help you avoid so-called “spaghetti coding”.

Addendum

Do you know that only 15% programs passes JSHint check? Isn’t it a food for thought?