Different programmers have different styles of coding. One would put curly braces at the same line as function names, while others would write curly braces on a new line. Some tend to name variables in camelCase, others in PascalCase. There is no right or wrong. It’s only a matter of preference.

At GO-JEK, we always have at least two people for code pairing & reviewing a project. The moment two or more programmers put their hands on a project, you’ll start to notice inconsistency across your codes. This inconsistency bothers my engineering conscience.

Obsessive Compulsive Disorder (OCD)

P.S. In this post I’m going to assume we are building a React app with create-react-app, although most of the concepts here are applicable to any Javascript development.

ESLint to the rescue

Luckily we are not alone and that’s why Nicholas C. Zakas built ESLint.

Its goal is to provide a pluggable linting utility for JavaScript.

You can either install ESLint globally or vendor as project’s dependency (preferred). Let’s install it as a project’s development dependency:

npm install --save-dev eslint

Then you can run an interactive initialization command:

./node_modules/.bin/eslint — init

You’ll be asked to pick any base rules you wish to extend and config file format. In our case, we pick airbnb-eslint-config as base rules and JSON as config format. Voila! just like in Unix, a runcom fossil is generated as .eslintrc file in project’s root directory. Here’s how it looks,

Let’s try to decipher .eslintrc relics,

env — By default, Airbnb config uses no-undef rule. If you use browser globals like localStorage or window in your code, these rules will cause linter to complain that those variables being never defined. Setting “browser” env key to true essentially tells linter, “Hey chill, I’m pretty sure these localStorage and window variables are defined by the browser. Don’t worry about it.” You can refer here for the list of supported env values. extends — These are the base rules you wish to extend. parser — This allows you to tune JavaScript transpiler and ES language features you like support. e.g. If you’re using ES6’s module system import React from 'react' , you might bump into the keyword 'import' is reserved error. This is because ESLint doesn’t know about ES6 features yet. To fix this, you need to install babel-eslint npm i --save babel-eslint and set it as the parser. rules — I don’t really agree with all Airbnb’s base rules. If you feel the same way, you can override them here. For example, Airbnb base rule by default pick react/jsx-filename-extension rule and only allows JSX tag to appear in .jsx files. To us, it makes sense to have JSX tag in .js files, so we added .js to the allowed extension.

Once you have fine-tuned the rules as desired, you could run:

./node_modules/.bin/eslint --fix <your_directory>

TADAAA! Your code is all fixed now! Except… Maybe not. --fix turns out to only support few rules. As you can see from this page, there are not many wrench (fixable) icons.

Name a more iconic duo. ESLint + Prettier. I’ll wait.

Make it Prettier

Prettier is a code formatter that works differently from --fix under the hood.

Prettier takes your code and reprints it from scratch by taking the line length into account.

One example of what Prettier can do that ESLint’s --fix can’t do is:

// bad

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

If you set max-len rule to 80, ESLint will just give you a warning that it’s too wide. If you use Prettier, it will format your code into this: