Writing clean JavaScript code with ESLint and JS-Beautify

When you are starting out as a programmer you are happy for every bit of success, no matter how small. The least thing on your mind is writing pretty code, all that counts is functionality. Quick results. Sometimes advanced programmers find themselves in a similar situation. During a hackathon or when customers pressure you into impossible deadlines, style is the least of your worries.

Unfortunately neglecting good and clean style can quickly come bite you in the behind. To avoid dumb mistakes and make projects scalable in the first place, you should introduce proper style early on in your development life.

Look at your code

Before you continue take a good look at some of the code you have written today. Now consider these two:

Is it legal? Is it stylish?

  1. Is your code compliant with the JavaScript rules and conventions? What would the compiler say? Is it legal?
  2. Is your code consistent and self-explanatory? Would other developers be able to quickly grasp what you’re doing?

Introducing linting

Humans are good at doing creative things, like writing, painting, or breaking the rules of programming languages. As such it is a good idea to analyse our code using programs that are much better at playing by the rules than we are. That brings us to the linting tools of the JavaScript world.

Linting is the process of examining your code and identifying syntax errors and style anomalies (also known as static code analysis).


First there was JavaScript, and it wasn’t all good. Douglas Crockford identified the good parts and distilled them into a tool called JSLint. It’s strict, it’s been around a while, but it gets the job done.
It has 22 documented options that you can use to customize its reporting behavior.


A bit younger, improved adaptation to your own rules – that is JSHint. It is probably the most used linter in the JS community. Everytime you find a github repo with a .jshintrc file you know they care about linting. Files and directories that should be excluded from linting are mentioned in .jshintignore.
With 69 documented rules it is more customizable than JSLint.


If all you really care about is style, then JavaScript Code Style is your companion. They work closely with the JSHint developers and there is consensus that JSHint will eventually focus on correctness only while JSCS is all about (personal or team) style.
At 100 documented rules pretty much any style guide can be matched, just put them inside .jscsrc and the linter will automatically pick them up. It also contains an option to exclude files.


The new kid on the block is ESLint. It is pluggable and can easily be extended. It combines the power of JSHint and JSCS and even though it is not as mature as those two it is ready for serious action and sports 169 documented rules that can be extended quite easily by plugins or own rules. It differentiates between warnings and erroOut of the linters presented here ESLint is the only one that will tell you which rules have been violated in the reporting process, making it the easiest to work with in my opinion.
All configuration can be done using .eslintrc and .eslintignore.

Performing a static code analysis

In order to install any of the linters you need to use npm and install them as regular modules:

$ npm install -g jslint
$ npm install -g jshint
$ npm install -g jscs
$ npm install -g eslint

Command line linting

You can now invoke analysis from the command line by calling the linter with the file or directory name of the code to inspect.
To analyze all files in the current working directory using ESLint issue:

$ eslint .

That will output a list of all found problems.

5 problems reported with eslint

Personally I do not find this command line reporting to be terribly helpful, as I need to go back to my editor and look for the files and lines to fix them. Fortunately there is a better way.

Linting in the editor

Most editors have plugins that allow you to use these linters during the editing process instead. Be it Sublime, Atom, or any of the IntelliJ editors, all support linting tool messages inside the editing workflow, which greatly increases productivity.

Lint plugins inside Atom

Worry less about fixing style issues

In an ideal world, editors should make it simple to write code in style and hard to violate rules. This is when some of the fixers enter the stage.

When working in a team or you are switching machines or even editors often you want all their settings to be the same. Editorconfig is a small but very versatile tool that can set 6 common options via an .editorconfig file. Once you have a configuration file and the editor plugin installed, everything works automatically.

Full blown IDEs usually have a code reformatter or beautifier, but also leight-weight editors such as Atom can be extended to use JS-Beautify (heralded by some as the de-factor standard for producing clean JavaScript code) which allows you to tweak 17 settings inside its .jsbeautifyrc config file. Beautification will not happen automatically, but usually it is initiated by pressing a key-combination (or selecting a menu entry). This affects either a selection, a whole file, or even the entire project.

For a more powerful beautifier take a look at esformatter. It comes with a whooping 286 documented settings and can bring your code into good enough shape to pass any of the linting tests, regardles how careless you code. In Atom it becomes a bit more complicated to use since you need to bring up the Command Palette and enter esformatter for it to perform its magic.

Comparing code fixers

Installing them is again done via npm install.

Bottom line of linting

As you see there are many tools available to support writing clean, stylish code. It needn’t be all complicated, even beginners can greatly benefit from a little effort on style.

To get started I suggest the following:

  • Install ESLint and use the minimum set of rules
  • Install Editorconfig and JS-Beautify to automate formatting as much as possible
  • Get used to performing lints within your editing workflow – don’t use them as a quality check after you’re done
  • Start with a small ruleset and introduce rules only as needed to avoid false positives. Nobody listens to a linter that reports thousands of violations

You can find my slides for a talk on this topic on slideshare and some sample code for Meteor projects on Github. This also contains documented and liberal rule configurations for jshint, jscs, and eslint.

Author image
Blogging since 2003 about life, tech, yoga. Passionate about the details and eager to know more. Systems theory meets empathy.
Bochum. Germany.