> * Many people consider JSHint, a fork of JSLint designed to be more configurable, a better choice.<p>This bullshit assertion is getting tiring. JSHint is not "designed to be more configurable", it's[0] JSLint with a different (and more permissive) base configuration.<p>JSLint defaults to enforcing Crockford's style and recommendation, but it also has all the knobs and levers required needed to make it accept pretty much any syntactically valid javascript you throw at it[1].<p>So when TFAA writes:<p>> For instance, of the three following if statements, only one is acceptable in JSLint:<p>TFAA is not disingenuous, TFAA is <i>actively lying</i>. How do I know? Because I read the documentation and I know that setting the `eqeq` option lets you use `==` and `!=` and that setting the `white` option will stop JSLint from caring about how you whitespace-separate your tokens, making all three styles "acceptable to JSLint".<p>You may not be arsed to configure your tools to match <i>your personal desires</i>, but don't lie about them, that's unbecoming.<p>[0] at its core, things may have changed and JSHint may have diverged further from JSLint, that does not seem to be the case when superficially checking their respective online demos.<p>[1] <a href="http://jslint.com/lint.html#options" rel="nofollow">http://jslint.com/lint.html#options</a>
Ironic that this is on the home page the same time the article about Bootstrap missing semi-colons is.<p>Crockford made it to keep himself from falling into traps and lets everyone else use (and configure) it too. That doesn't mean you have to use it religiously, I'm just glad for yet another tool in my drawer.
i've had similar issues in java, but have come to a different conclusion.<p>some context - i worked with java for many years, but more recently have been working mainly in python (with some js, c and clojure). recently i got a chance to work with a great client (and that means so much - a good client is about the best thing you can hope for) back in java. we decided to go with, amongst other things, maven and jenkins, and, as a result, i had some checkstyle reports "for free".<p>checkstyle is a little like jslint for java. you can configure it on two different levels. on the most basic level, you can simply disable/enable tests globally. i disabled just one test globally (the one that objects to attributes and parameters having the same name, for code like void foo(int bar) {this.bar = bar;}, because the ide works so much better with consistent variable names (auto-gen and renaming)).<p>more interestingly, the second level of config allows you to define comments that disable tests locally - on, or from a particular line, or for a block of lines. this is great, because it forces me to consider exceptions and, where they are needed, document there (the disabling comment can take extra text that describes why).<p>i don't particularly agree with everything checkstyle does. but i don't think that affects its main advantage. that advantage is not that it makes my code better, but that it makes it conform to a standard that others are used to, and - even better - that it documents why it deviates from that standard, when necessary. that last part makes particular sense because those deviations tend to be the "interesting" parts of the code - exactly the parts that should be explained in more detail by comments.<p>anyway, apologies if that seems off-topic. it just struck me that maybe jslint would be improved by a "document exceptions locally" approach (does it do that? all i know of is global config).
You have to put things back in context. JSLint was written in 2005 when no one really knew Javascript and there was no well-written open source Javascript.<p>JSLint was, and always is, a wonderful tool to educate people about Javascript common issues.