Hacker News new | comments | show | ask | jobs | submit login

> * 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




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


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.


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




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: