dean.edwards.name/weblog/2006/06/jslint/

Comment: #1

Full text of Michael’s post is http://jquery.com/discuss/2006-June/001545/.

Comment: #2

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.

Comment: #3

Just to reiterate what Michael Geary said, you’ve got to interpret the output. More at JSLint backlash.

Comment: #5

I echo Michael Geary’s comment–after I responded to this post, I edited my response somewhat to clarify that the problem is not really with JSLint. Douglas Crockford’s thinking was really the catalyst behind much of what I think and do regarding JavaScript, despite our different ideas about coding practices. It’s all about the shoulders of giants, I guess.

Comment: #6

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.

Comment: #7

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.

Comment: #8

My take?

JSLint is not harmful. Bending over backwards to pass the JSLint test is. Bending over backwards, generally, is a bad idea.

Comment: #9

The eval function is the most misused feature of JavaScript. That misuse is compounded by a design error in JavaScript which gives the evaled text way too much authority. JSLint assumes that eval is being misused. There are a few cases (such as the parsing of JSON text) where use of eval is correct. Because of those cases, JSLint provides a switch to turn the eval check off. I am puzzled why you created a $.eval alias. I can’t make any sense of that. Perhaps JSLint should look for use of eval as a method, so that others can avoid the same mistake.

Many of JSLint’s tests came from observing the comp.lang.javascript news group. Frequently, people would post pleas for explanation for why their code didn’t work. I saw many instances of things where the programmer misunderstood JavaScript’s sense of falsiness, and compounded that with a misunderstanding of JavaScript type coersion under the == operator, resulting in a difficult to diagnose error. I designed JSLint so that such errors could be detected automatically. It comes at the cost of a consistent and rigorous coding style.

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.

Comment: #10

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.

Comment: #11

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)

• Dynamic property access (Use bracket access for properties)
• Calling setTimeout, or setInterval (Use a pointer to a function, if you need to pass parameters, use a closure to bind the parameters to a function [This may require more explanation, ask if desired)

Comment: #12

@Juanito – I agree that eval is often misused. It is a powerful feature of the language however. Take a look at the source code of any of the major JavaScript libraries and you will find an eval somewhere. 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 eval is used legitimately.

Comment: #13

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

Comment: #14

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:

     Problem at line 16 character 21: Expected an identifier and instead saw 'do' (a reserved word).

     sscQuery.do(oSel, oNode, oCtx)) {

Who knew? Well, OK, *you* did, but I didn’t, and it saved me quite a bit of time!

Go JSLint!

Comment: #18

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.

Comment: #21

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.