Thoughts about JavaScript linters and “lint driven development”

I’ll start this article with a quick TL;DR question (which you’re obviously already know the answer to):

Should your team use a JavaScript linter?

YES. Absolutely.

That’s it. No need to read further than this.

Now that we answered the most urgent question let’s talk about linters and why you actually should (and want) to use them.

What’s a JavaScript linter?

A linter is a parser that parses your code and looks for mistakes. A linter could help you develop faster, keep your code organized, and do less syntax mistakes that potentially could cause errors and break your code.

In JS, using a linter will parse your code on-the-fly, and will let you know if your code is valid and written correctly. In addition, a JS linter could warn you about misusing your team’s code style.

A JavaScript linter in action.

Given the fact that every developer has its own style in code writing, working with linter that warns you about rules your team has defined in your code style guide, could help your team keep the code maintainable and readable for all — present and future developers.

Example of a very common dispute in code style:

if (goodDeveloper === true) {
// This is the way you should write "if" statements
}
if (goodDeveloper === false) 
{
// This is how evil developers are writing "if" statements
}

Another example is using tabs vs. spaces for indentation:

Based on true story.

Anyway, all of the above could be easily solved by using a linter. All developers will need to write code with standards they agreed (or mostly disagreed) on prior development.


A list of JavaScript linters

Personally after testing some of the above JS linters, I highly recommend using ESLint which I found very flexible and easy to use, as well as, has a great kickstart if you’re inheriting Airbnb’s style guide configuration.


Lint driven development. Or — should you enforce lint?

A few days ago I had a very interesting discussion in React Native Developers group on Facebook. I asked a question about how to enforce eslint in my React Native project, meaning, every time a lint error appear, the bundling process would break.

The idea I aimed for was to make sure everyone in the team are, and will be, aligned in writing code according to the team’s standards. I know, it’s a rough approach, some of you even might say it’s too rough, but from my experience, this approach works, and proves itself in the long run.

There’s another approach — a bit softer, says that using lint should be more a “way of life” rather than being enforceable rules that break your code. This approach proposing a more subtle solution that make lint part of your team’s day to day development process, same as code reviews, and TDD.

I call both approaches “Lint Driven Development” or LDD (which means also something not very important in Unix). It’s less important which one you choose, as long as using linters is part of the development process in your team.


So… What do you think? To enforce or not to enforce? Share your thoughts on comments.