A linter is formally classified as a Static Code Analysis tool. It is usually a command line tool and it parses a project’s code to look for patterns. It then checks the patterns it finds against generally accepted standards (or custom rules you think are important).
The primary purposes of a linter are to find errors, find bugs, and help enforce a standardized coding style in a project. When you implement a linter, it will do much more!
In the javascript ecosystem, the linters you will see most often are TSLint and ESLint. Both can be installed via npm and can make your software development lifecycle much faster.
In this post, I’m going to discuss why linters are important. Then, I’m going to show the typical ways in which linters are used.
Note: Most of my recent work has been in Angular. All examples in this post are using TSLint by way of the angular command line ng Lint
Linting is very important for a well functioning engineering team.
It finds errors in your code.
Let’s take a look at a quick example.
Here’s a common scenario that happens when writing code: a typo. Take a quick look at how the linter in your IDE would handle this.
A linter will catch this very quickly and you won’t think twice about it. Since the typo is underlined, you fix it very quickly and it takes less than two seconds. Imagine a scenario where you didn’t have a linter hooked up to your IDEA. You may continue writing code until you want to see how this works in a browser (let’s assume you’re not doing TDD in this example).
If you didn’t have a linter installed, you would probably continue writing code until you reached a point where you wanted to test it. You would upload your browser and it wouldn’t behave as expected. Maybe the date doesn’t look as expected. You might run a debugger or console.log a few items to see what’s occurring. Let’s say that it takes you less than 5 minutes to find the bug and fix it. Maybe it takes 30 seconds. Regardless, this could have been fixed in two seconds if you had used a linter. These little things add up over the course of a day, a week, a month, and a year.
Without a linter, finding the bug in your testing is the best case scenario. What’s the worst case scenario? Maybe, you never noticed a bug at all and this made it into production. I can easily imagine a scenario where you’re working with a codebase that has limited or no test coverage.
It increases team morale
Did you ever have a pull request that was torn to shreds by your fellow engineers? It’s not a fun experience.
It hurts your confidence. It can sometimes damage relationships with fellow engineers if they are brash with their comments.
Sometimes with on a PR with numerous comments, an engineer might hold back from commenting on other things.
A linter helps alleviate these issues by cutting down on comments related to coding style, clear mistakes, and bugs. When you hook a linter up to your Continuous Integration Pipeline or Continuous Deployment Pipeline (will be referred to as CI/CD pipeline in the rest of the article), you find those issues and stop the build before this gets to the pull request step.
Since a pull request now can’t get opened with these stylistic issues or clear errors in the code, this reduces the comments fellow engineers might make on a pull request.
This helps increase confidence of the individual engineer opening up the PR and reduces resentment towards other engineers.
It forces a cohesive, agreed upon style
Imagine you are a junior developer and you just opened up your first pull request. You are very proud of this accomplishment!
About an hour later you get your first comment. Veronica suggests that you should use a fat arrow function instead of the traditional javascript syntax. You’re eager to get this first pull request merged, so you quickly make that change and push code back up.
A half hour later, you get another comment on your PR. This time, it’s Michael suggesting that the code you just changed to a fat arrow function might be better off in the traditional javascript syntax.
Shit.
This happens to junior developers all the time.
Engineers come in all shapes and sizes. They come from different backgrounds and worked with different languages in the past. Good engineers are opinionated. Good codebases are opinionated too.
An agreed upon style is important for modern teams. You should have a style guideline that is supported by linting rules. If your team prefers fat arrow functions, make sure that’s a linting rule. If it prefers traditional javascript functions, make sure that’s the rule.
Your team should follow these rules unless there’s a few good reason to break it.
This helps code readability, code understandability, and the junior engineer experience.
It helps create a better overall architecture
Now that small errors and stylistic issues are being caught by the linter, peers on your team can now focus on other issues in your code.
Maybe the code doesn’t make use of the new architecture your team has adopted. Maybe there’s an inefficient line of code that will take long to execute as you scale. Maybe you named a function in a confusing way that might trip up others in the future.
Now that these style issues, clear bugs, and minor issues have been caught in the linter, the engineers on your development team can focus on deeper, more important issues.
This in turn, helps create a better overall architecture and codebase.
In practice, you would typically use a linter in three different places
These were all mentioned earlier in this post, but I wanted to make sure I mentioned them all explicitly here.
In your IDE
When connected to your IDE, linting errors will be underlined automatically so you can see them in real time when writing code.
In the command line
You can take a look at all the linting issues in your codebase by typing a command into your terminal. In an angular project, you would type ng lint.
In Your CI/CD Pipeline
Your CI/CD pipeline will use the terminal command to run the linter in your pipeline. You can then set the rules as you see fit to fail a build when a certain threshold is crossed.
A linter is engineering team’s best friend. They make your team faster, they make your team happier, they increase overall code quality, and they prevent bugs from getting into production.
Get my periodic email with the best resources and links online
https://tinyletter.com/rcavezza
Read more at my blog
Connect with me
Top comments (0)