Why you should always use a Linter

…and/or a pretty formatter

When I speak about linters there are some people that only think of them in relation to style guides. Well, it’s not only about that, even though that is important. A linter will also help avoid errors, and things that could not be errors (but look like them) or could be potentially dangerous.

A linter will help you catch bugs in a few scenarios. Such as:

const runnable = {}
if (Math.random() < 0.0001) {
  runable.run()
} 

With standard (a set of rules based on the eslint) this will give us two errors. The first one, runnable is never used and the second one on line #3 is using an undeclared variable. Obviously the two errors are actually one error: there’s a typo on line #3.

Detecting these errors whilst writing code and not when the app is running will save a lot of time — that could be a huge amount of time if the app is running in production. We could literally spend hours debugging in the worst case, but with a linter we get immediate feedback.

Another common error that a linter will help you to quickly avoid is:

const fs = require('fs')
fs.readFile('foo.txt', 'utf8', (err, data) => {
  console.log('data', data.toLowerCase())
})

With standard we will get an error: we are not handling the error in the callback function. Again, this could save us a huge amount of time debugging if someone experiences the error in production and we need to reproduce the problem.

Automation

There are many ways you can integrate a linter in your workflow.

Using a plugin in your text editor

The first step to getting immediate feedback whilst writing code is to add a plugin to your text editor.

Create an NPM script

Just add your linter as a dev dependency in your package.json and create a script like this:

{
  "name": "my-cool-package",
  "devDependencies": {
    "standard": "*"
  },
  "scripts": {
    "lint": "standard",
    "test": "npm run lint && test-runner-name"
  }
}

Standard is a set of eslint rules but it also comes with tools ready to use because their motto is: zero configuration.

As you can see there’s an NPM package called standard that provides a standard executable and that’s all you need.

You can also use eslint directly and configure choose your own rules, but I always prefer to stick to a popular configuration.

Git hook

You can also use lint-staged with husky or pre-commit, or simply having a small script that is invoked on a standard git pre-commit.

Automatic fixes

Another cool thing of standard (and eslint) is their --fix option. If there are only coding style issues those are automatically fixed with this option.

Prettier

Linters like standard let you keep a uniform coding style. But recently there’s another project that lets you go one step further: prettier. This pretty formatter understands the print-width. So for example this code is fine:

foo(arg1, arg2, arg3, arg4);

but this line of code is too wide:

foo(reallyLongArg(), omgSoManyParameters(), IShouldRefactorThis(), isThereSeriouslyAnotherOne());

So prettier will print it as:

foo(
  reallyLongArg(),
  omgSoManyParameters(),
  IShouldRefactorThis(),
  isThereSeriouslyAnotherOne()
);

Prettier has many available configuration options regarding identation, usage of semicolons, etc, but it also supports other languages such as: TypeScript, CSS, LESS and SCSS.

Prettier doesn’t help catching bugs because it’s just a pretty formatter, but nothing stops you of using both: a linter and a pretty formatter like prettier. In fact looking for standard + prettier will give you results for existing tools that integrate both.

Other style guides

There are other style guides for JavaScript. Such as the one they use at Airbnb and the one that Google suggests.

Standard is the one that I like the most, and if you love semicolons you also have semistandard.

It’s up to you to choose one. But just choose one, stick to it, and use proper tooling!