The Importance of Linting
This post is meant to be an overview of the usefulness of linting, with a practical use case as well as some examples of popular JavaScript linting setups.
Situation encountered
Recently, I completed a pull request in a library that I was using which was working perfectly for me when I had used Create React App to initialize my code but did not work while I was experimenting with Next.js. While I eventually ending up using Gatsby.js, the fact of the matter is that as a user of a JavaScript library, it is nice to not have to worry about whether it will work with a given framework because of a variable being used prior to declaration.
For both TypeScript and JavaScript, there are linting rules that can catch this exact situation - and ensure that it never happens. Bear in mind that this library had many tests, but because of a lack of linting rules this was not caught - and it may never have been if not for using it in a tool with a different transpile configuration.
So what is linting?
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.
But my team is great at keeping things the same - we catch any changes needed in code reviews!
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.
Ok, this might save some time, can you give me linters to get started for a few languages?
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.
What are some linting setups you have used?
For JavaScript projects I have worked on, I have used the Airbnb React/JSX Style Guide along with Prettier. Someone has created a nice bash script to help with setup (as with all bash scripts, please take the time to read it over yourself to make sure you understand what it is doing prior 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.
Examples
The following are two simple examples of some of the style differences.
Airbnb with Prettier
import React from 'react';
import { Box, Paper } from '@material-ui/core';
import propTypes from './Blockquote.propTypes';
const Blockquote = ({ children }) => {
return (
<Paper component="blockquote">
<Box margin={1} marginLeft={2}>
{children}
</Box>
</Paper>
);
};
Blockquote.propTypes = propTypes;
export default Blockquote;
standard JS
import React from 'react'
import { Box, Paper } from '@material-ui/core'
import propTypes from './Blockquote.propTypes'
const Blockquote = ({ children }) => {
return (
<Paper component='blockquote'>
<Box margin={1} marginLeft={2}>
{children}
</Box>
</Paper>
)
}
Blockquote.propTypes = propTypes
export default Blockquote
Fun examples, but why should I use either of these?
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.
What if I pick something, and change my mind later?
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.
Top comments (0)