Jslint Is Not A Code Quality Tool For 3rd Party Code | Hacker News Reader

Jslint Is Not A Code Quality Tool For 3rd Party Code

hughfdjackson.com

29 pointsinsin8 comments

> * Many people consider JSHint, a fork of JSLint designed to be more configurable, a better choice.

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.

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].

So when TFAA writes:

> For instance, of the three following if statements, only one is acceptable in JSLint:

TFAA is not disingenuous, TFAA is actively lying. 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".

You may not be arsed to configure your tools to match your personal desires, but don't lie about them, that's unbecoming.

[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.

[1] http://jslint.com/lint.html#options

It's fairly clear that the author was referring to the default configuration that JSLint ships with. Keep in mind that the original recommendation from the author JSLint was:

“There is one reliable, objective metric of JavaScript code quality that can help you in making your choice [… of library …]: JSLint. If JSLint finds problems in a library, then dump it and move on to the next one.”

This statement is fairly meaningless if it's reduced down to "if there's some set of configuration options to JSLint that allows this code to pass, then it's OK." Crockford clearly meant that people should evaluate library quality by the default configuration of JSLint.

You can configure a lot of options for JSLint, but not all of them. For instance, JSLint objects to the following:

new Entity(parentEntity);

This can't be turned off without modifying the JSLint parsing process.

(Yes, this is a rather odd bit of code, and it definitely should be flagged up normally. This is from a project where invoking a constructor would add the object to its parent object and trigger a GUI update.)

"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."

Mea culpa.

"TFAA is not disingenuous, TFAA is actively lying. How do I know?"

Reread the section. I have made it abundantly clear that this only applies if the default values are used.

I have updated the post to reflect your first comment.

Ironic that this is on the home page the same time the article about Bootstrap missing semi-colons is.

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.

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".

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)).

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).

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.

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.

JSLint was, and always is, a wonderful tool to educate people about Javascript common issues.

Reply on news.ycombinator.com