The linters are great tools that helps developers to improve code quality and even discover potential bugs. It uses static analysis approach and can provide almost realtime feedback when combining with IDEs / editors. It is more and more common for developers to adopt it and even some programming languages (ex. Golang) embedded a linter by default (and refuse to run if you got lint errors). But sometimes we might not use it in the best way, and I would like to share my two-cents in this post.

Linter at a glance

Let’s use eslint as an example to demo how linter works. When using linter, it is actually pretty straightforward and you just need to pass the path of source code as argument:

$ eslint src/**/*.js

And when there is an error, the output might look like this:

> eslint src/**/*.js 

/home/jeromewu/repos/app/src/App.js 
  10:61  error  'undefinedVar' is not defined  no-undef 

✖ 1 problem (1 error, 0 warnings)

If you are lucky, you code still works even with lint errors (even for the example above, if you code never execute the code contains this undefined variable, it still works). But it is recommended to fix all lint errors to reduce risks.

Although linter is useful, but sometimes developers may find it annoying as some lint rules are not easy to follow or your habit just different from the rules. And this is where I think some developers might misunderstand the purpose of linters.

Don’t just use linters, learn from lint rules

In my opinion, the purpose of the linters is not to find out the issues in our code and make our life miserable, but to help us to learn how to improve code quality according to the rules we applied. So the ultimate outcome should be us (as a developer) being able to write lint-error free code without linters reminding us all the time. So for me (and my team), the typical workflow with linters is like this:

• No matter which IDE or editor we use, install linter plugins to have realtime lint hints.
• Whenever encountering a lint error and we don’t understand why, check the website for explanation. (ex.  no-undef in eslint)
• If there is any rule that is not applicable in our use cases, turn it off for certain files or totally disable in configuration file. (Yes, it is totally fine to disable lint rules as long as you are sure about that)
• Repeat steps above and train ourselves to have less and less lint hints during development.

With this workflow and mindset, I believe linters are no longer your enemies, but good partners to help you improve and learn.

#linter #software #javascript #golang