According to Crockford, one of the main benefits of using JSLint is that it improves code quality by making it more consistent and less prone to syntax errors. It also helps ensure the quality of your code by detecting potential problems.
JSLint takes a different approach from other linting tools, which try to find bugs in programs and warn about them. Instead, JSLint tries to enforce the programming style defined by its creator.
Some people found this article useful, but there are others who feel that JSLint is too difficult to use. “It’s too strict,” they say, or “I can’t get my code to pass.” To address these issues, I thought I’d write a quick post listing some of the rules behind JSLint and explaining how they work.
I have been using jslint for a while now, but I am quite bad at remembering rules. My linter is setup and I don’t really pay attention to it anymore. I also don’t really use the official documentation.
So this morning, I decided to write a bit about the rules behind jslint. This will help me remember them, and I hope it will help you too!
What is jslint?
It is not just a linter; it’s actually a style guide that prevents you from writing bad code. It enforces good practices and makes sure your code follows some strict guidelines. The idea behind this is that if you follow all of them, you will have better code (which is true).
“Always use JSLint.”
“You’re wrong. Always use JSHint.”
“I know what I’m doing. I do not need a linter.”
In this blog post, I’m going to try to explain the different rules of JSLint.
I’ve been using JSLint for years and during this time, JSLint had a lot of changes. Some of them are pretty strange and some are annoying.
The most important thing to know about JSLint is that it is not more strict than other linter but it is just different.
But in order to use JSLint, you do have to know what all those error messages actually mean. So I decided it would be useful to write down the most common ones, just as a refresher. Just like you can’t remember everything by heart, JSLint can’t either. It’s not always easy to determine whether something is an error or not (especially when it comes to syntax), so sometimes it gets it wrong and refuses valid code. But if JSLint complains about something, there’s probably something wrong with your code.
In my last post, I discussed how to use JSLint with Sublime Text 2. Since then, I’ve received a few questions around how best to deal with errors in JSLint. One of the things that makes JSLint so useful is its ability to pick up subtle problems in your code. In this post, I’ll go over some of the rules that JSLint uses and how you can fix them.
Here are some of the more common problems that JSLint will pick up:
A leading decimal point on a number: .5, not 0.5
Octal literals (numbers starting with a zero): 010, not 8
Multi-line strings: “a\nb” instead of [“a”, “b”] or “a” + “b”
The ++ and — operators before variables (pre-increment and pre-decrement)
The delete operator applied to non-properties
Functions within blocks (more on this below)