JSHint: An Community Driven Fork of JSLint(badassjs.com)
badassjs.com
JSHint: An Community Driven Fork of JSLint
http://badassjs.com/post/3364925033/jshint-an-community-driven-fork-of-jslint
11 comments
Crock's contributions are massive, I agree. I'm so glad that we've had a JSLint in the first place.
However, JSLint has gotten increasingly more opinionated in the past few months.. For example, the standard for loop: `for (var i = 0, len = arr.length; i < len; i++) { ... ` will now error out in JSLint.
A lot of these sorts of changes don't have flags to customize, so that's something that JSHint aims to fix. Start with some great defaults, and allow them to be customized. Heck, we even save your checkbox preferences for you (via localStorage).
Crock's responses to people asking for changes on the mailing list have also been a little disappointing:
"Your sadly pathetic bleatings are harshing my mellow." http://tech.groups.yahoo.com/group/jslint_com/message/1688
On the github project, he's refused CommonJS convention, NodeJS export support, and Rhino compat -- all quite easy to do. So until Crock's primary JSLint is a bit more friendly to customizability and different environments, JSHint will fulfill those needs.
However, JSLint has gotten increasingly more opinionated in the past few months.. For example, the standard for loop: `for (var i = 0, len = arr.length; i < len; i++) { ... ` will now error out in JSLint.
A lot of these sorts of changes don't have flags to customize, so that's something that JSHint aims to fix. Start with some great defaults, and allow them to be customized. Heck, we even save your checkbox preferences for you (via localStorage).
Crock's responses to people asking for changes on the mailing list have also been a little disappointing:
"Your sadly pathetic bleatings are harshing my mellow." http://tech.groups.yahoo.com/group/jslint_com/message/1688
On the github project, he's refused CommonJS convention, NodeJS export support, and Rhino compat -- all quite easy to do. So until Crock's primary JSLint is a bit more friendly to customizability and different environments, JSHint will fulfill those needs.
Hi Paul, got an opinion on http://aresemicolonsnecessaryinjavascript.com ? I'm new to doing JS 'properly' and looking for some guidance here. Thanks.
Is there any reference for the reasoning behind error-ing on the standard for loop?
Problem at line 1 character 6: Move 'var' declarations to the top of the function.
I think Crockford is right about that error.
Declaration of variables in the loop could lead to this type of error:
http://cam.ly/blog/2011/01/javascript-interview-question/
(All of the 4 <li> will do alert('4') when clicked, when the programmer expects alert('1'), alert('2'), etc.)
If the variable had been declared at the top, that error probably would not happen.
Declaration of variables in the loop could lead to this type of error:
http://cam.ly/blog/2011/01/javascript-interview-question/
(All of the 4 <li> will do alert('4') when clicked, when the programmer expects alert('1'), alert('2'), etc.)
If the variable had been declared at the top, that error probably would not happen.
That error would have happened despite if the var was declared at the top or in the loop
addEventListener("stuff", function() {
return function(index) {
alert(index);
}
}(i);
Yeah. I meant that the mistake is less likely to have been made in the first place.
It's concerned about the declaration of i within the loop's first term. Since JavaScript only has function-level scope, that variable leaks into the broader context, which can lead to unexpected behavior.
Not if you actually, you know, know what you're doing. This dumbing down of programming does not work--if you have clueless people working on code, it'll end up broken, no matter how many tool-enforced 'best practices' they follow.
According to the JSHint website it is "an open-source project that is supported and maintained by the JavaScript developer community.".
However, the license still contains the following clause:
However, the license still contains the following clause:
"The Software shall be used for Good, not Evil."
Since it is a fork, we can't just change the original license. If there is somebody who is willing to explain if I legally can change the original license, I would be happy to do it. We consulted a couple of people and all of them suggested to keep the original in place. :(
Apparently this license was so perplexing for IBM laywers, that Douglas had to make a special exemption:
"I give permission for IBM, its customers, partners, and minions, to use JSLint for evil."
Previously posted on HN source: http://wonko.com/post/jsmin-isnt-welcome-on-google-code
"I give permission for IBM, its customers, partners, and minions, to use JSLint for evil."
Previously posted on HN source: http://wonko.com/post/jsmin-isnt-welcome-on-google-code
I bet IP lawyers everywhere are rubbing their hands in glee at the prospect of enforcing that license.
Why are they forking jslint instead of modifying Google's Closure lint? (http://news.ycombinator.com/item?id=1654082). Google's code has a more true open source license.
I would like to know the answer to this too, and what are the differences?
One thing I hated about jslint is that it would exit after catching a few "errors" too many, even if the errors were not actually syntactically incorrect. it's basically impossible to use if you're using jslint over large js projects that you don't own (I rarely go into someone else's js library to fix all of jslint's complaints!)
I'm guessing Crockford's code is extremely pristine, or that he's never used anyone else's code before.
I challenge anyone to run jslint over one of the many jquery libraries out there. I guarantee that there will be more than 100 errors per library, which is completely useless for debugging with all that noise.
I'm guessing Crockford's code is extremely pristine, or that he's never used anyone else's code before.
I challenge anyone to run jslint over one of the many jquery libraries out there. I guarantee that there will be more than 100 errors per library, which is completely useless for debugging with all that noise.
The default is 50 but you can tweak this value with maxerr option. So, to increase the number of errors before it stops up to a thousand do this:
/*jshint maxerr:1000 */
Douglas Crockford might be opinionated - and Anton Kovalyov and Paul Irish are fantastic fellows - but a fork of JSLint reminds me of the South Park premise: if you allow one episode to be censored then you in the end everything will have grounds for censorship... the fork looks all dandy now - as long as "the community" doesn't end up having too much say in the matter. It's a pretty dang big community we've got now ;)
Democratic governance of standards sounds better to me. I think this is long overdue. Best part is JSLint will still be around.
[deleted]
I find it odd that JSLint/JSHint is made up of one giant source file, seems like its setting a kinda bad example (unless such a thing is actually considered acceptable by javascripters).
<script>alert('XSS')</script>
'";?>
<?php echo "
ghjgjgjghj
Given that, I do agree that JSLint is sometimes more strict but you can change the flags to ignore those warnings if you'd like.