4 ms·

JSLint, The Javascript Verifier

36 points by mshafrir 17y ago

DanHulton 17y ago
Such a big fan of JSLint. Debugging thing is a lot easier if you de-lint your program first, because it gets rid of whole classes of possible errors. For anyone using Komodo, there's an excellent JSLint plug-in: http://community.activestate.com/xpi/kjslint-jslint-komodo http://community.activestate.com/xpi/kjslint-jslint-komodo, though you're limited to the version of JSLint they bundle in the plug-in. If you want to manually integrate the latest version into Komodo, I wrote a guide here: http://www.danhulton.com/blog/2008/01/16/integrate-js-lint-into-komodo-edit/ http://www.danhulton.com/blog/2008/01/16/integrate-js-lint-i... Seriously - de-lint your JS.
pmjordan 17y ago
Is there any particularly good, JavaScript-specific reason why the braceless version of if statements is discouraged? if (foo) bar(); Or is this just a matter of taste as it is with C, C++, Java, C#, etc.?
- Sephr 17y ago
  It's just a matter of Douglas Crockford's taste and he doesn't like them so you have to live with it.
  - tlrobinson 17y ago
    Along with increment/decrement operators, fall-through cases in switch statements, foo['bar'] style property access/assignment, bitwise operators, and a number of other things. His book ("JavaScript: The Good Parts") contains a lot of good information, but roughly half is what I would consider "style" preferences.
    - adamc 17y ago
      To be fair, he gives a very clear explanation of how he came to his opinion on case statements -- he started out favoring them. So it's more "opinion informed by experience" than just "opinion".
- DanHulton 17y ago
  Not javascript-specific, but it's well-enough documented that leaving out braces in if statements is a source of possible error. It's clearer and safer to use them.
- jdavid 17y ago
  if you want to do something like if (foo) bar(); you might as well write if(foo) bar(); i personally prefer if(foo){bar();} the reason to be explicit, is incase you are modifying your script via a compressor, sometimes you can not predict what line your code is going to be on, and its always best to be as explicit as possible. if you go to one of Crawford's talks, he mentions how he used to love writing switch case statements with fall through, until he spent hours debugging something because of it. most of the stuff he has in there is a really good start to having fairly readable and reliable code. i recommend following the pattern.
- litewulf 17y ago
  Javascript has implicit semicolon insertion. This means that some lines of code will not do what you'd expect if you make a dumb mistake.
Sephr 17y ago
I have yet to find something like JSLint that supports ECMA-357 (SpiderMonkey, TraceMonkey, ActionMonkey, Rhino, and Tamarin). Does anyone know of one?
jrockway 17y ago
It does catch one thing that my usual testing doesn't: trailing commas. I am in the habit of defining maps like this: var foo = { foo: "bar", bar: "baz", }; This works in Firefox, but not in IE. Arghhh! Perhaps I should do it Haskell-style: var foo = { foo: "bar" , bar: "baz" }; I find that to be pretty ugly, though, and think it's easier to just omit the trailing comma. Reluctantly.
- alexk 17y ago
  You can use Steve Yegge’s js2 mode, it detects issues of this type and warns you. http://code.google.com/p/js2-mode/ http://code.google.com/p/js2-mode/
  - mark_h 17y ago
    Just came here to post that. It really is amazing; incredibly handy for javascript development. (It even warns about redeclaring variables, all kinds of issues).
- axod 17y ago
  If you're minifying the js (Which is always a good idea), things like this don't matter too much.
bbuffone 17y ago
#Self Promotion Disclaimer - Eclipse Plugin for jsLint http://www.rockstarapps.com/joomla-1.5.8/products/jslint-eclipse-plugin.html http://www.rockstarapps.com/joomla-1.5.8/products/jslint-ecl...
wooby 17y ago
Javascript Lint is a nice Spidermonkey-based syntax checker you can integrate into your IDE. I installed it with macports, but it's here: http://www.javascriptlint.com/index.htm http://www.javascriptlint.com/index.htm In vim, I do: :set makeprg=jsl\ -process\ % which binds :make to a syntax check of the current file. It's a cool thing to put in an ftplugin.
camtarn 17y ago
Unfortunately, JSLint objects strongly to using 'new foo()' without assigning the result to anything, which is a pain if you're using Prototype AJAX since firing off an AJAX request is done by calling 'new Ajax.Request(url, options)'. The only way to get around this seems to be to put parentheses around the statement - there's no way to turn most individual checks on or off, unlike other static analysis tools I've used like PMD and FindBugs. I still use it - because that trailing-comma-in-hash-definition issue in IE is really annoying.

36 points by mshafrir 17y ago

Such a big fan of JSLint. Debugging thing is a lot easier if you de-lint your program first, because it gets rid of whole classes of possible errors. For anyone using Komodo, there's an excellent JSLint plug-in: http://community.activestate.com/xpi/kjslint-jslint-komodo http://community.activestate.com/xpi/kjslint-jslint-komodo, though you're limited to the version of JSLint they bundle in the plug-in. If you want to manually integrate the latest version into Komodo, I wrote a guide here: http://www.danhulton.com/blog/2008/01/16/integrate-js-lint-into-komodo-edit/ http://www.danhulton.com/blog/2008/01/16/integrate-js-lint-i... Seriously - de-lint your JS.

pmjordan 17y ago

Is there any particularly good, JavaScript-specific reason why the braceless version of if statements is discouraged? if (foo) bar(); Or is this just a matter of taste as it is with C, C++, Java, C#, etc.?

Sephr 17y ago
It's just a matter of Douglas Crockford's taste and he doesn't like them so you have to live with it.
- tlrobinson 17y ago
  Along with increment/decrement operators, fall-through cases in switch statements, foo['bar'] style property access/assignment, bitwise operators, and a number of other things. His book ("JavaScript: The Good Parts") contains a lot of good information, but roughly half is what I would consider "style" preferences.
  - adamc 17y ago
    To be fair, he gives a very clear explanation of how he came to his opinion on case statements -- he started out favoring them. So it's more "opinion informed by experience" than just "opinion".
DanHulton 17y ago
Not javascript-specific, but it's well-enough documented that leaving out braces in if statements is a source of possible error. It's clearer and safer to use them.
jdavid 17y ago
if you want to do something like if (foo) bar(); you might as well write if(foo) bar(); i personally prefer if(foo){bar();} the reason to be explicit, is incase you are modifying your script via a compressor, sometimes you can not predict what line your code is going to be on, and its always best to be as explicit as possible. if you go to one of Crawford's talks, he mentions how he used to love writing switch case statements with fall through, until he spent hours debugging something because of it. most of the stuff he has in there is a really good start to having fairly readable and reliable code. i recommend following the pattern.
litewulf 17y ago
Javascript has implicit semicolon insertion. This means that some lines of code will not do what you'd expect if you make a dumb mistake.

Sephr 17y ago

I have yet to find something like JSLint that supports ECMA-357 (SpiderMonkey, TraceMonkey, ActionMonkey, Rhino, and Tamarin). Does anyone know of one?

jrockway 17y ago

It does catch one thing that my usual testing doesn't: trailing commas. I am in the habit of defining maps like this: var foo = { foo: "bar", bar: "baz", }; This works in Firefox, but not in IE. Arghhh! Perhaps I should do it Haskell-style: var foo = { foo: "bar" , bar: "baz" }; I find that to be pretty ugly, though, and think it's easier to just omit the trailing comma. Reluctantly.

alexk 17y ago
You can use Steve Yegge’s js2 mode, it detects issues of this type and warns you. http://code.google.com/p/js2-mode/ http://code.google.com/p/js2-mode/
- mark_h 17y ago
  Just came here to post that. It really is amazing; incredibly handy for javascript development. (It even warns about redeclaring variables, all kinds of issues).
axod 17y ago
If you're minifying the js (Which is always a good idea), things like this don't matter too much.

bbuffone 17y ago

#Self Promotion Disclaimer - Eclipse Plugin for jsLint http://www.rockstarapps.com/joomla-1.5.8/products/jslint-eclipse-plugin.html http://www.rockstarapps.com/joomla-1.5.8/products/jslint-ecl...

wooby 17y ago

Javascript Lint is a nice Spidermonkey-based syntax checker you can integrate into your IDE. I installed it with macports, but it's here: http://www.javascriptlint.com/index.htm http://www.javascriptlint.com/index.htm In vim, I do: :set makeprg=jsl\ -process\ % which binds :make to a syntax check of the current file. It's a cool thing to put in an ftplugin.

camtarn 17y ago

Unfortunately, JSLint objects strongly to using 'new foo()' without assigning the result to anything, which is a pain if you're using Prototype AJAX since firing off an AJAX request is done by calling 'new Ajax.Request(url, options)'. The only way to get around this seems to be to put parentheses around the statement - there's no way to turn most individual checks on or off, unlike other static analysis tools I've used like PMD and FindBugs. I still use it - because that trailing-comma-in-hash-definition issue in IE is really annoying.