3 ms·

I'm a bit of an evangelical when it comes to static code analysis like this. I insist your code should work to a spec-- not necessarily Crockford's JSLint spec,

by bdg 15y ago

I'm a bit of an evangelical when it comes to static code analysis like this. I insist your code should work to a spec-- not necessarily Crockford's JSLint spec, but a spec, which is why I really like JSHint. But I find I can't really convince anyone of it being useful, I remember being in an interview for a startup I read about on here and started talking about this as a tool I use (they asked "What tools do you use"). They basically brushed it off as "yeah, I don't think this is super useful, we probably have bigger problems than a missing semicolon". As I understand it, general perception of people seems to be it's a tool for finding missing semicolons. I don't know how to give this a decent elevator pitch so other people can see the light.

mark_story 15y ago
Funny they should say that. An extra comma can take down multiple versions of IE, and is something tools like JSHint can easily catch. I can't think of a good reason not to use JSHint to catch stupid mistakes we all make.
bcrescimanno 15y ago
John Carmack wrote a great blog post a while back about Static Code Analysis. http://altdevblogaday.com/2011/12/24/static-code-analysis/ http://altdevblogaday.com/2011/12/24/static-code-analysis/ While not all of this is immediately applicable to JSHint and the like, it provides some insight into why static code analysis can be seen as helpful. As you also mention, it's really helpful for code within a codebase to be consistently written. JSHint can help enforce some of that consistency. This is where JSHint really shines. If your JS is tied to some sort of "build" process (even a short 1-2 second one), catching errors before running the build is incredibly helpful. If you intend to minify your JS code (as you should) before distribution, finding missing semicolons can be very important, indeed. I find the most helpful JSHint errors to be about mistyped variable names. It's so much easier to see that in my editor, fix it, and THEN run it in the browser.
simanyay 15y ago
I used to have this problem, now I just wait until the missing semicolon costs someone a day of debugging or a broken deploy.
billybob 15y ago
Funny, a missing semicolon was what convinced us to start lint-checking all our JS. We have a Rails app with multiple JS files. One of them ended with a statement like var foo = { /* object contents / } / no semicolon here */ This worked in development but broke in production. Browsers seemed happy to assume the missing semicolon when the closing brace was followed by the end of the file. But in production, this JS file had other files concatenated to it, and it broke. Lesson learned. We now use Syntastic to check our syntax in Vim, including Javascript.
drifkin 15y ago
JS static analysis tools can help you find mistakes that are often more serious than a missing semicolon. I've run into something like this before: for (var i = 0, len = items.length; i < len; i++) { var item = items[i]; // ...maybe some more code here... var subItems = item.subItems; for (var i = 0, len = subItems.length; i < len; i++) { // whoops } } The inner for loop's i & len variables are really the same as the outer for loop's i & len variables (there's no shadowing going on here because they're all in the same scope in JS). Depending on the order of things and how many subItems there are, you could end up with an infinite loop, iterating over the same items multiple times, or skipping certain items. It seems like it'd be an obvious problem to see, but if there's a significant amount of code above the inner for loop, you might miss it. It also seems like it'd result in very obvious bugs, but if subItems are rare, most of the time this code will run just fine. Most of the JS static analysis tools will complain about redeclaring i and len, which makes spotting this kind of problem much easier.

by bdg 15y ago

mark_story 15y ago

Funny they should say that. An extra comma can take down multiple versions of IE, and is something tools like JSHint can easily catch. I can't think of a good reason not to use JSHint to catch stupid mistakes we all make.

bcrescimanno 15y ago

John Carmack wrote a great blog post a while back about Static Code Analysis. http://altdevblogaday.com/2011/12/24/static-code-analysis/ http://altdevblogaday.com/2011/12/24/static-code-analysis/ While not all of this is immediately applicable to JSHint and the like, it provides some insight into why static code analysis can be seen as helpful. As you also mention, it's really helpful for code within a codebase to be consistently written. JSHint can help enforce some of that consistency. This is where JSHint really shines. If your JS is tied to some sort of "build" process (even a short 1-2 second one), catching errors before running the build is incredibly helpful. If you intend to minify your JS code (as you should) before distribution, finding missing semicolons can be very important, indeed. I find the most helpful JSHint errors to be about mistyped variable names. It's so much easier to see that in my editor, fix it, and THEN run it in the browser.

simanyay 15y ago

I used to have this problem, now I just wait until the missing semicolon costs someone a day of debugging or a broken deploy.

billybob 15y ago

Funny, a missing semicolon was what convinced us to start lint-checking all our JS. We have a Rails app with multiple JS files. One of them ended with a statement like var foo = { /* object contents / } / no semicolon here */ This worked in development but broke in production. Browsers seemed happy to assume the missing semicolon when the closing brace was followed by the end of the file. But in production, this JS file had other files concatenated to it, and it broke. Lesson learned. We now use Syntastic to check our syntax in Vim, including Javascript.

drifkin 15y ago

JS static analysis tools can help you find mistakes that are often more serious than a missing semicolon. I've run into something like this before: for (var i = 0, len = items.length; i < len; i++) { var item = items[i]; // ...maybe some more code here... var subItems = item.subItems; for (var i = 0, len = subItems.length; i < len; i++) { // whoops } } The inner for loop's i & len variables are really the same as the outer for loop's i & len variables (there's no shadowing going on here because they're all in the same scope in JS). Depending on the order of things and how many subItems there are, you could end up with an infinite loop, iterating over the same items multiple times, or skipping certain items. It seems like it'd be an obvious problem to see, but if there's a significant amount of code above the inner for loop, you might miss it. It also seems like it'd result in very obvious bugs, but if subItems are rare, most of the time this code will run just fine. Most of the JS static analysis tools will complain about redeclaring i and len, which makes spotting this kind of problem much easier.