As a developer, you’ve probably heard a lot about code style guides. They’re helpful sets of rules that coders should stick to. You probably use some of them in your everyday work. And that's great! But what if I told you that you can learn almost every single style guide in less than an hour and you don't even need to waste time examining docs every time you have doubts? Impossible? No! If you don't know them yet - say hello to linters!
If you're not familiar with the term “code style guides” - here's a short summary. Their main purpose is to keep a project’s code unified, clean and easy to read. It’s essential, especially when working with a team. If all developers follow such guidelines, the project’s code will be much easier to understand and to maintain for everyone else working on the project.
Check out these cool examples:
But there are no perfect style guides. Their power resides in the ability to customize them to your needs. This is also a reason why you should use linters - because different projects might have completely different style guides. This is where the magic of linters comes in. If you use them, it's not a problem anymore.
According to Wikipedia, the first “lint” was written in 1979 and its job was to find suspicious and non-portable constructs in C language source code. Sometimes, it's hard to believe that this was almost 40 years ago. Since then, a lot has changed and, of course, linters have evolved too. Some of their responsibilities have been moved to compilers, but they’ve also taken on new ones. For example - acting as the watchful eye of the style guide - and that's the point I want to focus on.
Nowadays, we have linters for almost every programming language, as well as for markup languages like HTML or even stylesheets. Basically, you can assume that any code that can be interpreted by a computer can be linted.
Here are a few linters that I use every day:
It's not a secret that pure knowledge is not the only thing that makes a good developer. There are many elements, such as resourcefulness, out-of-the-box thinking, communication skills (yeah, we're not just the guys in the basement anymore ;)), efficiency and the ability to learn new things. Linters are especially helpful with the last two. How? See the examples below.
When you start working with a language you're not familiar with - at some point, you’re inevitably going to feel confused. You may think: "How should I write this conditional? Should I use ternary operators? Is it good practice to declare multiple vars using one "var" keyword? What units are allowed here?"
Without a linter, you'll have to examine the style guide to find an answer or look for a solution elsewhere (sometimes the project won’t have a style guide, but still, there are some good practices you should stick to). There’s nothing wrong with memorizing all the rules (sometimes there are literally hundreds), but I’m firmly of the belief that there’s no need to do so. If there's a style guide - read it once or twice. That's all. Then, let the linter do its job.
Depending on its configuration, the linter will inform you about inconsistencies with the chosen style guide while you’re writing code, saving a file or running tests. My preference is to have it do so while writing code and running tests. It saves the most time and gives you the best opportunity to pick up good habits and learn how the code should be written. Why also lint while running tests, instead of only while writing code? The answer is simple - always double check your work. Sometimes you'll miss something during the edit, you won't notice an error etc. That's where linting during tests helps you out.
Instead of learning every single rule from the new style guide - let the linter do this for you. If you're familiar with the language - with the linter’s help you'll rapidly learn the new principles and can start coding right away. You won't have to examine docs all the time because the linter will notify you when you’re doing something improper.
Yes, linters do this too. They provide simple syntax checking, so you don't have to waste time searching for that one missing semicolon. It will show you exactly where it needs to be. Unclosed bracket? No problem. The linter will handle this too. Typo in a function name? You'll know where it is before you even notice that something doesn't work. Maybe you want to use an undeclared variable? Gotcha. The linter won't let you do that. But these examples are just the tip of the iceberg.
There are a few ways to use linters - in an editor, as a standalone service or inside tests. The decision is yours. Personally, I use Atom as my editor and linters usually work out-of-the-box with it. But there are no obstacles to using them with your favourite editor (there are packages for Vim, Sublime Text, Notepad++ and many, many more).
Here are some useful links:
There are also IDEs with built-in linters - like WebStorm or IntelliJ, which are also fully customizable and very easy to use.