JSLint Considered Harmful
Michael Geary has posted a great comment on the jQuery mailing list:
Did JSLint actually reveal *any* hidden bugs, or did it just complain about perfectly legitimate coding practices such asMichael Geary
Leave a comment
Full text of Michael’s post is http://jquery.com/discuss/2006-June/001545/.
Just to clarify (and avoid making enemies!), I’m a huge fan of Douglas Crockford and his work. When I said “JSLint considered harmful” I was referring specifically to the snafus with jQuery and the stylistic nitpicks. JSLint looks a valuable tool: Now that I know about it, I’m going to start using it myself. I’ve had bugs in my own code that JSLint would have found. I’ll just know to take its warnings with a grain of salt.
On JSLint.com, Doug solicits feedback about the program and asks specifically if it is too strict about any of its warnings. What would be perfect is the ability to turn off any of the warnings, as it allows now for a few of them.
As a quick and dirty fix for my own use, I’ll probably just grab a copy of the code and comment out the warnings I don’t want.
Just to reiterate what Michael Geary said, you’ve got to interpret the output. More at JSLint backlash.
For a lint tool to be really useful, it should be an automatic part of your testing procedure. If it always spits out a few meaningless errors then you’ll miss the important ones when they’re in the middle of them. You’ll soon get tired of interpreting the results. So I think a lint that cries wolf just isn’t very useful.
Another harmful post? Well in all due respect, it’s much more helpful than it (possibly) is harmful.
All in all, if you know what you’re doing, you know which errors to turn on and which ones to turn off. Use eval in the proper places, and take them out when you might have screwed up. This argument can go both ways. If you take it out but yet you’re polluting your code with unecessary eval’s then yea, it would be nice if a tool would catch those.
JSLint encourages consistency – and that in my book isn’t harmful.
JSLint is not harmful. Bending over backwards to pass the JSLint test is. Bending over backwards, generally, is a bad idea.
JSLint does not disallow — and ++. It does provide an optional check for post-increment and post-decrement because these have been implicated in many of the worst buffer-overrun security errors. I found that when I stopped using them, the quality of my own programs improved. You may have different quality goals, so you don’t have to activate that test.
If the source is as JSLint expects, it generates a function report. It lists for each function:
* The line number on which it starts. * Its name. In the case of anonymous functions, JSLint will “guess” the name. * The parameters (including arguments if used). * The vars. * The global vars. An unexpected item here can be an indication of an error. * The labels.
You can include in your program a comment that lists the global functions and objects that your program depends on, but that are not defined in your program or script file. Including this information can improve the quality of the report that is generated.
An external declaration can look like this:
/*extern getElementByClass, breakCycles, JSONRequest */
A global declaration starts with /*extern. Notice that there is no space before the e.
Select the Assume a browser option to predefine standard global properties that are supplied by web browsers, such as window and document and alert.
I also believe that there is almost no good use for eval. Reading json data from an asynchronous transaction seems to be the only good candidate. Does anybody know of any others?
The following are non-eval solutions if you’re tempted to use eval
Common Misuse (solution)
@Juanito – I agree that
evalsomewhere. Are library authors doing something wrong? Of course not. Those calls are deep in the code and are accessed rarely but they are needed.
JSON is a good example of where
evalis used legitimately.
Ironically, I just today made some code work in your JS Packer only because JSLint (running through TextMate) found code that did not adhere to Packer’s requirements (of ending every line with a semi-colon).
Since the code I was trying to pack was from a large group project w/thousands of lines of JS, after looking to make sure FUNCTIONS ended with semicolons, I was all out of ideas until JSLint sniffed out the problem for me.
So yeah, I’d say it has some use and reveals *some* bugs
JSLint finds bugs for me once in a while. I agree it’s too persnickety. But I sleep easier knowing that Packer or some other compressor won’t fark my code because I dropped a semi.
Besides, just today I had a runs-everywhere-but-IE moment, and JSLint gave me this:
Who knew? Well, OK, *you* did, but I didn’t, and it saved me quite a bit of time!
[…] Randnotiz: Der hier muss natürlich wieder rumstänkern, aber das gehört wohl zu jedem guten Nerd-Blogger, der etwas auf sich hält […]
[…] http://dean.edwards.name/weblog/2006/06/jslint/ […]
I use JSLint first any time I have more than a few lines of code because it saves me time. Being told exact lines to fix things and my code running right immediately after that is so much nicer than tromping through trying to find what the browser is complaining about.
[…] http://dean.edwards.name/weblog/2006/06/jslint/ […]
[…] об обнаруженных ошибках. Однако у общественности нет однозначного отношения к данному проекту, да и тема тестирования JS-приложений требует […]
It’s funny to see so many people saying JSON is a valid application of eval(). It’s not: it’s far too general. Doug wrote a specialised JSON parser, https://github.com/douglascrockford/JSON-js, where native JSON parsing ( http://wiki.ecmascript.org/doku.php?id=es3.1:json_support ) is not available.
[…] Criticism: http://dean.edwards.name/weblog/2006/06/jslint/. […]
Comments are closed.