Techmeetup Edinburgh have just updated their Vimeo page with the talk I gave on JavaScript linting and hinting earlier this month.
As a reminder. The slides and references from the talk are available here: Material From Techmeetup Talk
Here is the material from my Techmeetup talk in Edinburgh on Wednesday 11th July
Many thanks to those that attended, hope you enjoyed it.
The Prezi presentation is available here: http://prezi.com/nlwom16jo6z7/javascript-static-analysis/
Code location [TBD]
http://www.jameswiseman.com/blog/2011/03/31/jslint-messages-document-write-can-be-a-form-of-eval/
http://www.jameswiseman.com/blog/2011/01/18/jslint-messages-eval-is-evil/
http://www.quora.com/Is-JavaScript-the-most-popular-programming-language-in-the-world
“Assembly Language of the Web”
http://stackoverflow.com/q/11340673/144491
http://stackoverflow.com/q/2665984/144491
http://tech.groups.yahoo.com/group/jslint_com/message/1688
https://github.com/twitter/bootstrap/issues/3057#issuecomment-5135562
http://wonko.com/post/jsmin-isnt-welcome-on-google-code
http://anton.kovalyov.net/2011/02/20/why-i-forked-jslint-to-jshint/
http://brendaneich.com/2010/11/paren-free/
WScript Files: http://jameswiseman.com/jslint/
Netbeans Plugin : http://plugins.netbeans.org/plugin/40893/jslint
Eclipse Plugin : http://stackoverflow.com/questions/2741058/jslint-eclipse-plugin
Eclipse Plugin additional info: http://stackoverflow.com/questions/2741058/jslint-eclipse-plugin
Emacs Plugin: https://github.com/daleharvey/jshint-mode
http://closure-compiler.appspot.com/home
https://developers.google.com/closure/compiler/docs/error-ref
https://developers.google.com/closure/utilities/
http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml
http://code.google.com/p/closure-linter/source/browse/#svn%2Ftrunk%2Fclosure_linter
I stumbled across this message recently during the course of developing a bespoke jQuery plugin for one of our systems.
The offending code in question was
/*****************************************************************************/ /*Private functions. /*****************************************************************************/
Given its structure, I found myself blinded to the offending code until I spotted that I had indeed omitted the closing ‘*/’ from the second line.
The message it yielded in full was:
Stopping, unable to continue. (4% scanned).
This message is easy enough to understand, but it’s one of those that causes JSLint to halt in its tracks
The omission of a closing statement to any block of code can result in inadvertently nesting any proceeding code. Block comments are more forgiving of the omission, because the second opening ‘/* will be treated as a comment itself.
However, consider the following:
/*Private functions. /*Nested Comment*/ */
In the above code, the first close-comment will close everything, and the second will be left dangling. This is even shown up by the syntax-highlighter (if you can see it).
One user did ask this question of Douglas Crockford, who responded
JSLint stops because it sees comments that are nested. That is usually
an indication of a serious coding error. In the face of such errors,
JSLint stops.
So there we have it. Don’t nest your comments.
This article is one of a series on the error and warning messages produced by JSLint.
When referring to function arguments in JavaScript, we almost always refer to them by the name by which they were passed:
function foo(a) {
var b = a; //refer to the function parameter 'a',
//....
}
However, there is an object representing these arguments to which we can refer. This is the arguments object.
This object provides us with some useful properties, which include .length and .callee. It also allows us to refer to the argument by position like so:
function foo(a) {
var b = arguments[0];
}
It is this use of the arguments object that JSLint complains about. Variables are given names to identify what they are and what they mean. There are a valuable tool for writing self-documenting code, and referring to them in any other way makes little sense. You’re also relying on the argument being in a particular position. If you ever change the order of the arguments in the function definition, you’ll have to change the index by which you reference each argument.
Moreover, unless your variable name is longer than 12 characters, you will require more keystrokes to refer to the arguments themselves. In addition to this, opimisers like GZip which can give variables and arguments shorter names for compression and obfuscation purposes are likely to skip over these instances, reducing the compression capability of your code.
Refer to this post on JavaScript arguments at seifi.org for more information on the arguments object.
A Guide To JSLint Messages
This article is one of a series on the error and warning messages produced by JSLint.
Most developers are have instilled within themselves certain fundamental core programming practices. Possibly the most famous of these is the DRY (Don’t Repeat Yourself) Principle, which states that duplication can lead to maintenance nightmares, poor factoring, and logical contradictions.
But as with many principles in programming, there are always trade-offs, and times where the rigorous application of a principle can be unhelpful and even counter-productive.
The counterpart to DRY is WET (Write Every Time), and there are scenarios where it makes sense to duplicate code, as described in the articles: Write Every Time Dilutes performance Bottlenecks and Beware The Share.
Another principle that is preached almost religiously is the efficient management of resources, and one strategy for doing this is to allocate any resources as late as possible, and release them as early as possible. The use of block scoping is a particularly common key for achieving this.
This gives rise to code similar to the following:
var a = 1;
if (x === a){
var b = 2; //'try' giving variable 'b' block scope
//do other stuff
}
In languages such as C++, C# and Java the above convention would limit the scope and lifetime of the variable ‘b’ to the ‘if’ block.
JavaScript, however, has no block scoping, and any variables declared within a block will be ‘hoisted’ to the top of the nearest scope when the code is picked up by the compiler. This is either the nearest containing function, or global scope. In short, this will make them visible outside the originally intended scope.
JSLint is all about reducing bugs, and had the author of this StackOverflow question run their code through JSLint, then they may never have had to ask a question at all.
If you really wanted to enforce scoping down at this level then the following convention might help:
var a = 1;
if (x === a){
(function(){
var b = 2; //give variable 'b' (pseudo) block scope
//do other stuff
}());
}
Here we’ve wrapped the code in an anonymous function, and invoked it immediately (thanks to the set of parens at the end).
Yeah, sometimes it does.
I have tried to remain neutral in all my posts on JSLint messages to date. Here, however I am going to jump off the fence and offer a sentiment of bafflement.
JSLint deems some errors so serious that it immediately ceases scanning. For me this is understandable in the event that it encounters utterly unparsable code and literally cannot continue, however, I just don’t understand why it must stop dead with the following:
for (var x=0; x<10 x++){
//do something
}
And it appears I am not alone. A very similar query posted on the JSLint GitHub repository failed to yield any explanation before the thread was closed.
Any ideas anyone?
This article is one of a series on the error and warning messages produced by JSLint.
Periodically, I check the JSLint update history on GitHub to see what’s going on, and what significant updates have been included.
So, imagine my surprise when I saw a simple one-line comment on a June 12, 2011 edit:
eqeq
I did a quick diff on the source code to see this following line added:
// eqeq true, if == should be allowed
This means that you can now configure JSLint to ignore uses of ‘==’, where previously it would have insisted you should use ‘===’
At the time of writing it hadn’t been updated on the JSLint front page, however testing locally with the following yielded no ‘==’ related warnings:
/*jslint eqeq: true*/
var x = 0;
if (x == 1) {
alert("test");
}
I always recommend that use the ‘===’ in this instance anyway, but I am aware of the differing opinions surrounding it. Ultimately, you can make your own decision (and it is ‘on’ by default so you have to opt-out).
An incorrect placement of the ‘break’ statement within a loop will yield this error message. As shown in the following example:
function MyFunc(){
var x = 0;
for (x=0; x<10; x++){
//do something
break;
}
}
Here, we will never reach the second iteration of the loop.The ‘break’ statement will kick us out at the end of the first time around. Break statements used in this way should always be wrapped in a conditional statement.
At best this is redundant code that was never cleared up properly, and, at worst, this is some sort of bug that is yet to be identified.
A Guide To JSLint Messages
This article is one of a series on the error and warning messages produced by JSLint.
In languages where compilation of code is required up-front before it can be executed, the developer often has the luxury of being warned about unused or unreachable code by the compiler.
For JavaScript, we have no such luxury, however, JSLint is there to emulate some of the features that a compiler would provide.
So, when we write code that contains unused variables, JSLint will helpfully warn about us about it. The following code sample will yeild this error:
function MyFunc(){
var x = 0;
for (x=0; x<0; x++){
//do something
var y = 0;
}
}
At best this is redundant code that was never cleared up and, at worst, this is some sort of bug that is yet to be identified.
A Guide To JSLint Messages
This article is one of a series on the error and warning messages produced by JSLint.
