Heh, the old Netscape specs are kinda loose. In a recent blog post, Andrea Giammarchi reminded me that if (x == null) is the same as writing if (x == null || x == undefined) (and also removes your responsibility of ensuring that undefined is really undefined.) Once in a while I’ll use that if I don’t care about whether the next developer understands Javascript’s many coercion nuances.

You’re certainly right about just using if (obj) some times. If the docmentation clearly states that we’re expecting an object for a parameter (or something else that won’t coerce ambiguously), I’ll use that. Until ES5, it’s by far the fastest and lightest way to detect missing args — and, imho, the easiest to read.

So now I’m trying to use braces for one-liners. Maybe I’ll get used to it.

Eventually.

(@Pankaj, yah, I found the bug the old-fashioned way: alert() statements!)

var test = 0;
/*jslint: eqeqeq: false */
if (test == false) { /*jslint: eqeqeq: true */
doStuff();
}
/*jslint plusplus: false */
for (test = 0; test < 5; ++test) { /*jslint plusplus: true */
doMoreStuff()
}

Of course, there doesn't seem to be an option to allow == null – since null and undefined are distinct values, "typeof(test) === 'undefined' || test === null" indicates to the next programmer (with fewer bytes than a comment) that you know precisely what your variable should contain.

Definitely agree with #3 – if you post your issue on http://tech.groups.yahoo.com/group/jslint_com/ Douglas usually responds very quickly.

if ( Expression ) Statement else Statement
if ( Expression ) Statement

{…} (a block) is technically a statement in itself (a statement that contains statements). I tend to use blocks because, oddly, I find them more readable.

With the variable declaring issue, I always opt for declaring ALL variables at the top of the function — you may as well, considering that they’re all going to be “hoisted” there anyway…

I’ve never had to use obj == null … most of the time this is exactly the same as just “obj” in a boolean context. (i.e. if(obj){…} or !!obj).

Gotta hand it to Doug, he’s sure streamlined the work he does on JSLint.

PS Old Rasputin FTW!

For instance, it also didn’t like that I used unescaped curly braces in my regular expressions or that I used escaped line endings in my strings. I imagine those might break some of the dumber minification tools.

I didn’t see any options for those on the site. I think they should put some text in the options to let users know. Something like “Want more options to configure jslint? Download it for full control.” Or something like that.

Joking aside, though, you can configure it so it only spits out errors and warnings that you do care about, which is what I respect about JSLint; not forcing itself upon the user with self-righteous demands. While I do agree with some of the points you’ve raised (especially using clauses like the ‘==’ you mentioned earlier), this tool is draconic for a reason – there’s a myriad of developers who come from all sorts of backgrounds, and JSLint helps with the most common eyesores and no-nos.

While I agree, this tends to align itself with the way Apple treats its users (lock ‘em out since they don’t know what they’re doing), but the fact that with a little configuration you can get only “your” good parts out of the parser, which makes it an excellent tool.