The advantages and limitations of JSLint: a blog about when to use JSLint.
JSLint is an excellent tool for catching coding errors, but the jury is out on whether or not it improves code quality. On the one hand, it helps people avoid programming pitfalls such as using eval. On the other hand, it enforces arbitrary rules such as requiring semicolons at the end of all statements (something that I personally dislike).
When JSLint is used in conjunction with unit tests and code reviews, it can be very useful. There are some cases where JSLint can help you find errors that might otherwise go unnoticed, but there are also times when JSLint will report false positives (e.g., when using Google Closure Library’s goog.exportSymbol function). In general I think it’s better to err on the side of caution and rely too heavily than just enough because if you rely too little then your codebase may become riddled with bugs that could have been prevented easily by simply running JSLint before committing changesets to version control software like Subversion or Git/GitHub.
The advantages and limitations of JSLint should be understood before using it as part of your development process. This article discusses them with examples drawn from real-world use.
It is important to use the right tool for the job. JSLint attempts to identify several suboptimal coding patterns, which are sometimes useful but sometimes not. JSLint’s rules can be categorized in terms of their motivation:
1. Performance: will this code run slowly?
2. Reliability: might this code produce incorrect results?
3. Correctness: does this code conform to the style guide?
4. Security: could this code expose a security hole?
5. Readability: will another programmer be able to understand this code?
6. Maintainability: will you be able to change this code later?
7. Simplicity: are you doing too much work for no benefit?
1) It enforces patterns that avoid dangerous coding practices such as using eval() or with().
2) It can be used to enforce coding conventions within a development team.
3) It can be used to enforce coding standards that are set out in a style guide.
4) It allows only one way to do something (for example, it does not allow the use of switch when an if/else statement could be used). This can result in inefficient code that is less readable for developers who are not familiar with Douglas Crockford’s style guide. JSLint also doesn’t allow the use of certain functions such as parseInt() that should be supported by all browsers but aren’t (e.g., Internet Explorer 8).
5) Sometimes it just doesn’t make sense (e.g., when using jQuery and other libraries).
It’s good to know about tools like this but I tend to think that they are only valuable if they can be integrated into your build process or unit tests.
I found this post while looking for something else and it made me think about the importance of choosing the right tool for the job.
There are many occasions when you want a tool to tell you that your code is wrong. You might want to check for typos, to ensure that all of the variables and functions in your program have been declared, to ensure that the program does not use any forbidden or unsafe features, or just to ensure that your code follows some particular coding convention.
JSLint is a good choice if you want to check for typos and variable declarations. JSLint is also a good choice if you want to enforce some particular coding convention.
However, I would argue that JSLint is almost never a good choice if you want to ensure that your program does not use any forbidden or unsafe features. The reason is simple: JSLint was never intended as such a tool and it doesn’t do it well.
There are no rules. There are only tools and goals. When you use lint-like tools, your goal should be to reduce the number of errors in your program while writing as little code as possible. The tool will supply suggestions that you may adopt or reject based on your own experience and judgment. The best way to learn how to use lint-like tools is to read the literature produced by their creators, Doug Crockford and Mike Samuel respectively.
JSLint was created by Douglas Crockford as a successor to DCLINT (the DECUS C LINT program) which was created in 1987 by