I wanted to see if JSHint had a provision for checking imported packages for property names in a file it was, um, "hint"ing, and ran into a link to the, "Why I forked JSLint" post (which was down -- domain now points to github? -- but lives at archive.org) again. The post is interesting. The representative example given to fork JSLint is a horrible one, imo. Kovalyov argues that he should be able to put a var before a iterator variable, like this...

for ( var name in obj ) { ...

That's really not a good reason to leave JSLint. Forcing you to acknowledge variable hoisting doesn't seem that objectionable. There are other things that it forces you to do that I don't see as much wisdom in, but this really isn't one of them. And that his snippet has "Example taken from jQuery 1.4.2 source" as if that made it automatically something worth emulating also gnaws at my craw a bit.

But the post's epigraph from Crockford does resonate:

Your sadly pathetic bleatings are harshing my mellow. โ€”Douglas Crockford.

Wow. Reminds me of the link I use in my StackOverflow profile to undercut where I quote, "You should take JSLint's advice," a bit. The guy's a great coder, and I enjoy his very strict approach to JavaScript 99.44% of the time, but Kovalyov is right: Crockford's social skills (and, from what I've seen, hubris) are awful.

But again, bad social skills don't make the tool just as toxic. Kovalyov links to Brenan Eich, "creator of JavaScript", where Eich says, "JS Lint can suck it" That's said, sure (Eich is using automatic semicolon insertion, though he's doing it to make his code look like CoffeeScript, so Kovalyov has already taken the quote well out of context), but there's an interesting counterpoint Kovalyov misses in that same blog post from Eich:

Here's my pitch: committees do not design well, period. Given a solid design, a committee with fundamental disagreements can stall or eviscerate that design out of conservatism or just nay-saying, until the proposal is hardly worth the trouble. At best, the language grows larger more quickly, with conservative add-ons instead of holistic rethinkings.

What I like most about JSLint is that I know I'm getting similar code across the board. JSLint honestly enforces well-considered conventions. When Kovalyov says, "It is quickly transforming from a tool that helps developers to prevent bugs to a tool that makes sure you write your code like Douglas Crockford," my reply would be, "And you think your committee is going to do better?"

So many questions about JSLint on StackOverflow get answered with, "You should use JSHint." But if we all use JSHint to turn off whatever bugs us, as we'd do if we followed that advice each time, what do we leave turned on? Just the things that aren't troublesome? Isn't our code getting lint-i-er each time? Show me an example of where what Crockford requires from you is wrong -- not just annoying, but undeniably worse than an alternative. I don't think it exists, yet.

Isn't the point of a linter to challenge us all to write better code?

Labels: , , ,