JSLint is a static code analysis tool used in software development for checking if JavaScript source code complies with coding rules. It was developed by Douglas Crockford.
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.
Since it was released in 2002, JSLint has been controversial — many people dislike its approach and want to use it as little as possible. But if you are a JavaScript developer, you should know how it works and what it can do for you. In this article, I’m going to cover some of the basic rules behind JSLint as well as give some advice on how to use it correctly.
A couple of weeks ago, I wrote about the fairly controversial JSLint tool – in particular, about the fact that you can use JSLint to discover bad practices and potential errors in your JavaScript code automatically.
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.
For those who don’t know, JSLint (and its cousin, JSHint) works by analyzing your JavaScript code and spotting problems with it. In some cases, these are real errors, like missing semi-colons or assigning values to undeclared variables. However, many of the warnings that JSLint throws up aren’t strictly errors at all – they’re just bad practices or potential pitfalls. For example, it’ll warn you if you have duplicate parameters on a function declaration. Or if you’re using ‘==’ instead of ‘===’. Or if you’re using “eval” inside your script!
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?
JSLint is a code quality tool written by Douglas Crockford. It was first released in 2002, and it’s still being maintained today (even though it hasn’t been updated for 3 years). He wanted to create a tool that would fix bad Javascript code automatically. After realizing it was impossible, he created JSLint, which instead of fixing the code tells you what is wrong with it (warning: this is not what linters do).
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.”
These debates have been going on for years among JavaScript developers. JavaScript is a unique language, and it certainly does not help that our community is so divided when it comes to code style. It’s no wonder why newcomers are so confused about what tools to use and how to write their code.
In this article, we will go over the rules of JSLint and make some recommendations on how to write clean, maintainable code. This article assumes you have at least some familiarity with the language and its quirks. If not, we recommend reading JavaScript: The Good Parts first.
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.
If you use JSHint or ESLint, I invite you to take a look at this post to see if your habits match with what a JavaScript developer should do.
If you’re like me, then once in a while you need to refresh your memory about some basic JavaScript rules. And because I don’t want to clutter my head with this kind of stuff, I use JSLint as a reminder for all those little rules, best practices and quirks of the language that have a tendency to slip my mind.
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)