Linting is a way to programmatically check that your code is following a set of rules. The rules used vary from project to project and can vary greatly depending upon preference. Rules vary from code style (tabs vs spaces, what line does the curly bracket go on) to enforcing best practices (all variables must be declared before use, or use array forEach when iterating an array instead of traditional for i=0 syntax), and can become a very strict safety net or simply unify the format of code.
If this is the case, then you are on one of the most disciplined teams that I have ever heard of. Assuming that you are correct, how many hours total are used to do code reviews? I remember when one of my teams first sat down and agreed to follow a set of rules - specifically John Papa's Angular 1 Style Guide so that we would not need to come up with our own rules. We kept realizing that we missed something, or dealing with old code that had not followed these rules and so trying to swap between styles was a pain. As we caught many things in reviews, eventually we started using code linters so that we would not have to keep track of everything manually and yet could still have complete confidence that the rules were being followed.
Glad you asked, here are a few language linters that can work across a variety of development environments. Visual Studio Code integration links are included because that is the environment that I like to use.
However, I have also used standard JS which is a little easier to get running with as there is not any configuration to worry about. Taking the time to look at both may be useful for your team before deciding.
The following are two simple examples of some of the style differences.
As you can see, both have their own unique style, and if your team would want to do more configuration manually then you would not be easily able to do so with standard JS. Both are reasonably well known, and both are easy to use in code editors. For pure formatting, both have a
--fix option available to run as well.
If you have enabled an extension directly in VS Code, you may also get a handy pop-up message with either one, similar to the following.
Basically - the reason to use one of these styles is to avoid the need to have someone coming up with more rules as a full-time job. By simply picking something and going, you can easily start running making use of the experience others have had.
For the purpose of this article, I took my main codebase for this site and converted it from the Airbnb and Prettier configuration and moved to standard JS. This took about fifteen minutes, as there were not many differences that the
--fix option did not take care of. However, from experience, I know that if you are starting with no linting rules even a medium-sized project can take several days to make compliant depending upon how it was written and how many logic styles currently exist, as you may have rules such as no-plusplus or no-for-in-array which are fairly simple to address but start to add up over time - especially if someone made use of clever logic.