Even if you’ve never seen or heard the word linting before, I can guarantee that you’ve seen one in action. I’m using one right now: a spell-checker.
A spell-checker (and much more so, a grammar checker) exists to try and identify problems in your text. It points out where you’ve typed something wrong, which you need to fix for your document to be correct. Your spelling and grammar errors may not make your text completely unreadable, but correcting them ensures that your document meets certain standards (the standards of the language you’re writing in).
You can implement a linter in various ways. It can be run from the command-line, or be built into your build process so that code won’t be shipped unless it passes the linting test. My favourite way to lint is in my text-editor. It means that you can catch problems as soon as they’re written, and be thinking about code quality all through development (not just when you’re ready to ship).
Benefits of linting
We can also use linting and style guides to enforce sensible and consistent formatting, like whether
if statements should ever be one-liners. These can seem trivial and nit-picky (particularly if you like your particular coding style!), but they make it much easier for all developers to quickly parse documents without having to ask “what is this supposed to do?”. If you’ve ever come across code written by fans of ternary operators, you’ll know what I mean.
var foo = bar ? baz : qux === quxx ? bing : bam;
As well as stopping us making silly mistakes and enforcing coding best practices, linting can be used to ensure general good behaviour, like commenting your functions. It’s a coding Swiss Army Knife to improve the quality of your final output.
In many places throughout our style guide, we’ve tried not just to state what the rules are but also what problem they’re trying to solve.
for, forcing 4 space indents).
In 2010, JSLint was forked into JSHint (whilst JSLint continued to be developed). The fork intended to allow more customisation possibilities so that developers had more freedom to determine their own set of standards.
Then, in 2013, JSCS emerged. Whilst JSHint focussed more on ensuring your code was free of mistakes and bad practices, JSCS set out to allow developers to easily enforce code style. JSHint without JSCS was ensuring your code was very stable. JSCS without JSHint was making sure it all looked the same.
ESLint has been around since a similar time to JSCS, but didn’t hit version 1.0.0 until June 2015. Since then, it has quickly become a developer favourite and a standard choice throughout the industry. ESLint again blurs the line between code quality and code style, meaning that where previously JSHint and JSCS were used side-by-side, you now only need one tool. It comes with a myriad of rules, all of them off by default so (in stark contrast to the original JSLint) there is no “suggested style”.
ESLint also has great support for future versions of ECMAScript, allowing you to easily lint ES6 code and use additional rules specific to new features, making it helpfully forward-thinking. Alongside this, it is configurable, so you can easily add your own rules.
ESLint has really cemented its place at court with two recent developments. On April 14, the JSCS team announced that they were deprecating the project and moving to ESLint, citing that they would rather work together to create a unified tool than have two competing products trying to solve the same problem. A few days later, the jQuery Foundation announced that they were going to officially support ESLint going forward. This means that ESLint is no longer relying on individual maintainers, and will continue to be owned by the community rather than any big business.