Benefits of using a linter in JavaScript

Benefits of using a linter in JavaScript

We can say that JavaScript is a “conflictive” language. It’s true that other languages also allow the developers to write some ugly code, but JavaScript is super permissive regarding coding style.

The thing is worse when you are working in a team, basically because everyone can have a different style. It can lead to conflicts and an even uglier code.

A good solution for this is to use a linter. A tool that will take you (and all the team) in the right way while writing code and help you to maintain the same coding style all along the project. I’ve been using ESLint for a while, so let’s take a look at some key points that I’ve noticed.

Consistent coding style for the project

These days a lot of people use Visual Studio Code for JavaScript. A few of them prefer to switch between IDEs depending on what they are going to code; if you need to write some Java or Python code, you might prefer something more specific.

If you don’t configure your IDEs properly, you’ll have indentation issues that will lead to a misaligned and hard-to-read code, that’s annoying, but is just the tip of the iceberg.

In those first stages where your project is doubling its code base every day, you’ll surely try different patterns, styles to declare variables, classes, functions, etc. That will basically impact the collaboration in the future since it might be hard to start coding in a project with mixed styles.

ESLint is great to avoid that, you can define a style for your project and combine them with some custom rules. This will make sure that everyone on the team is following the same convention. I personally prefer the Airbnb stylebut you can use whatever you like the more.

Avoid bad practices

By using a linter, you’ll get a lot of good practices in addition. Some of the default rules may sound ridiculous in the beginning, but I promise you that if you put a bit of effort, you’ll understand that there is a reason behind them.

Default rules like disallow params reassignment, disallow reassigning exceptions or disallow variable or function declarations in nested blocks may be natural and reasonable for some people but are not for others.

Just take some time to read about the rules and decide if it’s ok for your project. Maybe your project depends on some of those bad practices and you simply have to continue living with them.

Reduce merge conflicts

As time runs, your code will become cleaner and more consistent. In my experience, some subtle changes like adding a comma at the end of an array item, have saved me from merge conflicts.

Also, with the help of a linter, the code will be easier to read, since most of the bad practices tend to complicate the code.

I hope these points are good enough to encourage you to use a linter and improve your code. If you have any experience working this way or you’d like to try it out, please comment in the box below.

Regos Dev Studio is a product development company that builds add-ons for Jira, Confluence and LiveChat, combined with development of custom solutions in a variety of languages.

Don’t forget to check out our website, visit our Atlassian marketplace listingand our apps for LiveChat. You can also follow us on Twitter and stay tuned for updates!

Leave a Reply

Your email address will not be published. Required fields are marked *