A code “Linter” takes a look through your lines of code for possible errors, and also enforces certain styling conventions. Generally, this shows up as a red underline in an IDE, or a console output after starting your program.
It is not a true error checker, though. For that, you need to actually run your code and write tests.
Linting serves one main purpose: making your code consistent. Everything else is a nice side effect.
When you are a solo developer, you may not care about writing tests or making your code readable for the future. Even still, a linter’s consistency helps with the simplest thing: getting your code to work on the first try. I would recommend a linter anytime you are writing more than 100 lines of code. For many IDEs, there is no required setup. We all know and appreciate testing frameworks, but those can be a chore to set up, especially for small projects.
If you are using an IDE, a linter will probably be bundled in with whatever language support you already have. For example, the VSCode Python extension has a built-in linter following PEP8 syntax. If you do most everything with the command line, you may have to follow some steps to install a linter. Things like
create-react-app may come with linting built-in, that will run when you start the app.
Linters can often catch simple errors. Usually, this is unused variables, or variables that have not yet been declared. Other possibilities include incorrect function calls, incorrect typing, and import errors. I personally feel that testing is unnecessary for smaller personal projects. A linter plus your own iterative process is usually good enough.
Linters don’t actually execute the logic of the code, so they cannot catch off-by-one errors. Don’t expect them to solve all of your problems.
Believe it or not, linter readability is mostly for your own benefit. Recently, I have mostly been developing solo. When you return to projects after a few months, you will find that it takes a lot of effort to get back into them. This will be lessened by their readability.
In my opinion, the most important aspect of coding is fulfillment. Trying to debug your own damn code is not fulfilling. If you can move quickly, your motivation remains higher. This goes beyond linting, of course. You should always break your code into meaningful functions and maintain a human-friendly structure. Sometimes it is nice to have less to worry about, though.
Linting makes your code readable for other people, but who really cares about that?
This goes hand-in-hand with whatever style guide the linter is based on (and is mostly exclusive to frontend languages). Accessibility notifications always surprise me, which is why I appreciate them. Most of the suggestions will be incredibly simple, like adding alt-text to an image tag. Accessibility is incredibly important, but it is difficult to memorize all of the conventions. Linters are just another tool that help the layman improve the range of their apps.
Different Style Conventions
Error checking is never dependent on style. Unused variables will always be picked up by a linter. Style differences more commonly affect things like spacing, top-level import styles, and function documentation. Some linters will support newer features, or plugins. Some will be more opinionated.
Originally published at https://elliott-king.github.io on September 2, 2020.