JSLint, The Javascript Verifier | Hacker News Reader

JSLint, The Javascript Verifier

jslint.com

36 pointsmshafrir16 comments

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.

You can use Steve Yegge’s js2 mode, it detects issues of this type and warns you.

http://code.google.com/p/js2-mode/

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

If you're minifying the js (Which is always a good idea), things like this don't matter too much.

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, 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-i...

Seriously - de-lint your JS.

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

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.

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

It's just a matter of Douglas Crockford's taste and he doesn't like them so you have to live with it.

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.

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

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.

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.

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.

#Self Promotion Disclaimer - Eclipse Plugin for jsLint

http://www.rockstarapps.com/joomla-1.5.8/products/jslint-ecl...

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.

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

Reply on news.ycombinator.com