“JSLint” is a JavaScript “code quality tool”. If you’ve never heard of it then think of it as the W3C HTML validator, but for JavaScript. Doug Crockford, the genius that created JSLint, frequently claims that JavaScript is “The World’s Most Misunderstood Programming Language”; if you want to know where he’s coming from with this statement then you’ll have to purchase his book, “JavaScript: The Good Parts” or, for a brief overview, watch the Google Tech Talk.
In some ways JavaScript could be considered just as lax as HTML when it comes to what is acceptable and what isn’t. For example, most browsers will let you get away with HTML that looks like this:
<ul id =list> <strong><li>One <strong><li>Two <strong><li>Three |
And, similarly, most, if not all, browsers will let you get away with JavaScript that looks like this:
function muahaha() { myarray = new Array() myarray['name1'] = "056" something = parseInt( myarray['name1'] ) if(something==56) for (i=0;i<myarray.length;i++) if(myarray[i] != null) return true return false }; |
How many things can you count in the above code that are either bad practice or just incorrect usage of the language? If we go by JSLint then there are a total of 16 problems with it! Plus there are a couple that aren’t noticed by JSLint (using an array as an object & accessing myarray.length
on every iteration). That’s 18 altogether! Yet, all browsers will run this code quite happily without throwing a single error.
Technically, it’s all legal JavaScript (minus the extra semi-colon at the end), so I’d expect all browsers to munch it up without complaining.
So, if it works1, then why should you take that extra step to ensure best practices; what’s the point and who will benefit?
For starters, there’s you! When you need to maintain or add to this code you’ll find yourself spending many more minutes doing so than if the original code has been written with best practices in mind. Although, honestly, you are the last person that you should be worrying about. What on earth is another developer going to make of this?
Good practices exist for a reason; not following them generally leads to bad things. Don’t use JSLint because you have to, use it because you want to!
1 – The function won’t work as expected (parseInt('056') !== 56
) but it will “work”; as in, it won’t throw any errors. Actually, just completely ignore the muahaha
function; it doesn’t do anything; it’s just an example of awful code.
Thanks for reading! Please share your thoughts with me on Twitter. Have a great day!
Yeah – JSLint is a great tool. I enjoyed “JS: The Good Parts” as well, but all of those diagrams were confusing.
JSLint is insanely helpful… and above all it has saved me a lot of headache, especially when it comes to IE debugging, because IE (6 in particular) is actually less forgiving than for example, firefox, and the IE script debugger isn’t particularly helpful. Also I’m a sloppy coder, not by heart, but I tend to miss a lot of semicolons as i type away and some trailing commas in objects, arrays etc.
Highly recommended!
ps. quote: It may hurt your feelings 😛
JS Lint hurt my feelings. I’m intimidated now…
I think JSLint needs to be updated though, as it sometimes shows some odd ‘errors’, like requiring that you add filters to all ‘for in’ loops.
That doesn’t hurt my feelings, just makes me wonder if the tool itself is worth using.
Great post!
I don’t mean to nitpick here, but… Indeed,
parseInt('056') !== 56
, but how is this “unexpected behavior”?If the string passed to the
parseInt()
function begins with'0'
, and no radix parameter is given, the radix is implicitly set to8
(octal).If you want to parse decimal numbers, you need to use a radix of 10.
parseInt('056', 10) === 56
Thanks for the comments! 🙂
@Jeffrey, agreed, I don’t think I really understood any of those diagrams – but he seems to really like them; he uses them in some of his presentations too.
@Daniel, I should’ve included that tagline – it is certainly true. The first time I used JSLint the results were not pretty! But, over time, it’s definitely made me a better JavaScript developer!
@Alex, don’t be intimidated; try to embrace JSLint! 🙂
@Pete, agreed, plus its implementation seems a little shallow in some areas. For example, it will throw an error with this:
But not with this:
… even though, effectively, they’re the same.
@Mathias, by “unexpected” I meant from the author’s perspective (i.e. the fictional person who wrote that function). Understandably, the ignorance of that fictional individual lead to him/her being unaware of the radix issue.
Great writeup!
Question – how come you’re not plugging your hugely useful Lint-deployer Debug here? Simply not ready yet?