For a long time, I’ve thought that code linting tools (linters) were a good idea in principle, but too annoying to use on a regular basis. Besides, I’ve always been pretty particular about my coding style, so I felt like I didn’t need a tool to help me do something I already do anyway.

I have used SmallLint (a.k.a., the Code Critic) to good effect in my Visualworks Smalltalk projects, even going so far as to write some additional rules and integrating the tool into my automated builds. But even there, some of the rules would produce false positives that I didn’t think needed to change.

As our team started working with ES6, React, and Redux, we decided to adopt linters to help us out. I was a bit reluctant, but we all felt like it would be good to have some “training wheels” as we were learning the new tools. I privately felt like we’d probably out-grow the need for linting after a month or two.

I have to come right out and say it: I was totally wrong.

We adopted ESLint for JavaScript and sass-lint for CSS. We set up initial configurations for both tools that matched the way we wanted to write our code, and we’ve since evolved them as we’ve gained more experience.

Both tools are really nice. Lots of rules with enough flexibility that we can mostly adapt them to our preferred style. It has been relatively easy to work them into our process so that the lint errors and warnings are in our face.

We also use Atom as our text editor, so we’ve all installed the linter-eslint and linter-sass-lint plugins as well. By default, both tools show you lint warnings as you type. You can turn that off so that they only run when saving files, but I was surprised to find that I really like the instant feedback.

ESLint is able to fix many lint violations automatically when run from the command line. linter-eslint recently added support for this feature as well, so you can configure it to automatically fix lint issues when you save the file in Atom. This is quite handy and it keeps me from having to manually fix some of the issues.

ESLint supports plugins, and we’ve found two that we really like. eslint-plugin-react adds a number of rules for React and JSX code. And eslint-plugin-import adds a number of rules for checking imports. We have it configured to warn us if we’re trying to import from files that don’t exist, import things that aren’t exported, or if we mix up default vs destructured imports. That plugin alone has saved us from more hair-pulling confusion than almost anything else we’ve done.

I’ve also used Rubocop for Ruby a little bit, though not much yet in Atom. There is a linter-rubocop plugin for Atom. The next Ruby project I work on, I plan to get Rubocop going early based on my surprisingly pleasant experience with ESLint and sass-lint.

It can be difficult to adopt linting tools on an existing codebase, especially when much of the code violates the linter-enforced style. In that case, you might consider a CI-integrated tool that only runs the linter on modified lines of code. For this purpose, I know of pronto and Hound, though I’m sure there are more options out there.

In general, I’ve been really pleasantly surprised by my experience with these linting tools. I recommend you give them a try yourself and see what you think.