Why Bother?

JSLint contains a number of messages pertaining to the style, appearance and formatting of JavaScript code. This includes stipulations about bracing positions, indentation and spacing.

As a demonstration of this paste the following into http://jslint.com/

var x = 0;
switch(x){
    case 1:
        x++;
        break;
    case 2:
        x--;
        break;
    default:
        break;
}

Zero errors, right? Now click the flag ‘Strict white space’ (‘white’) and recheck…

Yikes! 10 errors (at the time of writing)!

So why should JSLint possibly care what your code looks like? After all, it’s all about bugs, isn’t it?

Well, on the surface, legible code equates to more maintainable code, which itself equates less ambiguity and fewer bugs. But you may have your own internal guidelines that dictate how the JavaScript looks, i.e. how you indent, where you put your braces, etc. So you will have probably flipped the ‘white’ flag to ‘off’. After all, when given the above code snippet, JSLint returns a substantial amount of what you consider to be ‘noise’, which if no use to you. Right?

However in turning this option off, you are missing the opportunity to have a uniform and consistent convention across your code base, and a tool that can tell you where you are deviating from it.

But sometimes, formatting and positioning does have functional implication as well, and can lead itself to bugs. Consider the following code:

function GetObjectLiteral()
{
    return
   {
       x:0,
       y:1
   };
}
alert(GetObjectLiteral().x); //what do you expect?

Regardless of what you expect the above to return, what you will not get is an alert box with the text ’0′. Different browsers may behave differently. IE8 complains about a missing semi-colon, whilst others will simply execute the ‘return’, passing control back to the calling function, and then fail to find the member ‘a’

Changing the bracing position fixes the code:

function GetObjectLiteral(){
    return{
       x:0,
       y:1
   };
}
alert(GetObjectLiteral().x); //alerts '0'

The Messages

So, let’s have a look at some of these messages…

Expected ‘{a}’ at column {b}, not column {c}.

This is a simple case of incorrect indentation. The most basic demonstration of this can be seen in following code snippet:

var a = 0;
  var b = 0; //Problem at line 2 character 3: Expected 'var' at column 1, not column 3

Expected ‘{a}’ to have an indentation of {b} instead of {c}.

This is another indentation catch. The default indentation step is 4, meaning that indentation columns should start at positions 1, 5, 9, 13, 17, etc. The sample below uses an indent of 5 spaces, placing the start of the new column at character 6 (as the message denotes).

function MyFunc() {
     alert("hello"); //Problem at line 2 character 6: Expected 'alert' at column 5, not column 6.
//3456789
}

Expected exactly one space between ‘{a}’ and ‘{b}’.

This message goes some way to supporting JSLint’s assertion of correct bracing positions. You will see this message generated on the following code snippet.

if (x === 0)
{  //brace on next line
    alert("hello");
}

But even when you do place the brace on the correct line, JSLint requires you to apply the correct spacing. So, the following code snippets will also yield this message:

if (x === 0){ //no spaces
    alert("hello");
}

if (x === 0)  {//two spaces
    alert("hello");
}

Missing space between ‘{a}’ and ‘{b}’.

Haveyoutriedreadingsentencesthathavetheirspacesomitted? Generally, it’s not that easy, is it?

if (x === 0){    //Missing space between ')' and '{'
    alert("hello");
}

Mixed spaces and tabs.

This message is displayed when a line is indented with a mixture of spaces and tabs. Most IDEs will have an option to convert tabs into spaces automatically. I suggest you turn this on.

Unexpected space between ‘{a}’ and ‘{b}’

Here, JSLint is reporting that you have included a space where it did not expect one. The following code snippet will yield this message:

if ( x === 0){  //Unexpected space between '(' and 'x'
    alert("hello");
}

A Guide To JSLint Messages

This article is one of a series on the error and warning messages produced by JSLint.

In JavaScript we can assign a function expression to a variable, like so:

var foo = function() {
    return 1;
}; //assign function expression to 'foo'

This is perfectly valid, and often useful.

It is also possible to assign a variable the return value of the function expression by invoking the function, like so:

var foo = (function() {
    return 1;
}()); //assign '1' to 'foo'

This is also valid, although less commonly useful.

These are two distinct techniques with distinct conventions, so, the following may well give rise to confusion:

var foo = (function() {
    return 1;
});//assign function expression to 'foo'

The above is equivalent to the first sample of code, and will execute in exactly the same way. JSLint encourages you to wrap invoked function expressions with parentheses. Wrapping non-invoked function expressions in the same way may be indicative of something non-intentional, or at very least be misinterpreted by a future developer.

In other words, stick to the first convention for the assignment of function expressions.

A Guide To JSLint Messages

This article is one of a series on the error and warning messages produced by JSLint.

This is the longest error message that JSLint boasts. In full it reads:

“Wrap an immediate function invocation in parentheses to assist the reader in understanding that the expression is the result of a function, and not the function itself.”

What a mouthful!

This is relatively simple to explain, however:

var a = 1 + function() { return 1; }(); //assigns '2' to the variable 'a'

The JSLint error can be addressed by adding parentheses around the function:

var a = 1 + (function() { return 1; })(); //assigns '2' to the variable 'a'

However, this will yield another JSLint message Move the invocation into the parens that contain the function.

So, of course to address this, we wrap the whole invocation with the parentheses, like so:

var a = 1 + (function() { return 1; }()); //assigns '2' to the variable 'a'

So what is the reason for this? Well, actually, the message itself explains is quite well: “Assist the reader in understanding that the expression is the result of a function, and not the function itself.” Not all of JSLint is about bugs and problems. Some are all about achieving a consistent style. This is one of them.

This is similar to another wordy JavaScript message: Function statements are not invocable. Wrap the whole function invocation in parens, which captures isolated unwrapped function declarations. Seen in the following example:

var a = 0;
function foo(a) {
    alert(a);
} (a);

Here, we can see that, again, the invocation is missing a wrapping parentheses. However, in direct contrast to the first example, the code immediately above will fail.

A Guide To JSLint Messages

This article is one of a series on the error and warning messages produced by JSLint.

JSLint reports this error when a function name has been omitted from a functions statement. For example:

function(a) {
    alert(a);
}

It is possible that the original intention was more like the following:

function foo(a) {
    alert(a);
}

Although, it is also conceivable that a function expression was also intended:

var foo = function(a) {
    alert(a);
}

A Guide To JSLint Messages

This article is one of a series on the error and warning messages produced by JSLint.

This message was acutally too long for the subject title. In full, it reads:

“Function statements should not be placed in blocks. Use a function expression or move the statement to the top of the outer function.”

We can reproduce this message with the folllowing code:

var a = 0;
if (a === 0) {
    function b() {
        alert(1);
    }
} else {
    function b(a) {
        alert(2);
    }
}
b(); //call the function. But which one?

The intention is to decalre a function based on some condition, but this doesn’t necessarily work, and the condition is likely to be ignored. Instead we are at the mercy of each inditidual implementation of the JavaScript interpreter.  With the above examples, we may see either “1″ or “2″ alerted.

To achieve what we are attempting we need to use a function expression, like so:

var a = 0;
var b;
if (a === 0) {
    b = function() {
        alert(1);
    }
} else {
    b = function(a) {
        alert(2);
    }
}
b(); //call the function.

This will work every time.

A Guide To JSLint Messages

This article is one of a series on the error and warning messages produced by JSLint.

With this message we move deep into the heart of JavaScript closures. Without wanting to engage into a discussion about what they or their relative merits are, we can examine how this message might arise. Take the following code:

var a = 0;
(function(a) {
    alert(a);
})(a);

The parentheses around the function are necessary, because when omitted, the compiler assumes it is a Function Statement (see links below).

When referring to ‘Invocation’ we actually mean the bit of code (a) at the very end of the block of code. Although the code itself will execute perfectly, JSLint prefers that everything is more self-contained, so insists on the following convention instead:

var a = 0;
(function(a) {
    alert(a);
}(a));

This is almost identical, except the invocation (a) now appears within the parentheses that wrap the function.

The most convincing for me is that the initial parentheses isolates the block of code that is being invoked by the second set of parentheses. In addition to this, JSLint has been designed specifically to eliminate conventions and behaviours that have been proven to lead to bugs and issues, so it is possible that sometime in the past the first convention has yielded a bug or some sort of issue.

Some Links

The above function code follows a convention more commonly known as the JavaScript Module Pattern

To demystify the mire of Function Declarations, Function Expressions and Function Statements, refer the article Named function expressions demystified by Juriy “kangax” Zaytsev.

Also thanks to StackOverflow for helping me answer this: Question –  Solution for JSLint Errors

A Guide To JSLint Messages

This article is one of a series on the error and warning messages produced by JSLint.

JSLint has very specific constraints about how you use new. This message is displayed when JSLint encounters an object that has been constructed using new Array() instead of simply = [].

In JavaScript we can declare a new array as follows:

    var a = [];
    var a = new Array();

This example is innocuous – they both achieve the same effect – an empty array. But what if we want to add some initialisation?

    var a = [5];  //new array one in size contaning the value 5
    var a = new Array(5);   //new array five in size, each item 'undefined'.
    var a = new Array('5');   //new array one in size containing the value '5'

Well, here our problems start, as the comments indicate. The first declaration initialises an array with a single value ’5′, whereas the second declaration initialises an array of five ‘undefined’ values. The third declaration, however operates differently to its immediate predecessor, initialising an array with a single value ’5”.

While they all might be what is intended use of new Array() is subject to inconsistency and confusion. In addition to this, once constructed, we have to do a subsequent assignment to add new values. Using the literal notation we can perform the assignment upon declaration.

Furthermore to this, the Array keyword could also be overridden:

    Array = {};
    new Array(); // TypeError: Array is not a constructor

Whoops! Of course, I would question the wisdom of overriding ‘Array’, but nevertheless, using the array literal notation would help us steer clear of this problematic scenario.

Special thanks to the respondents of Stackoverflow for helping me write this article – Stackoverflow Question – JSLint: “Use the array literal notation []” for var os_map = {}.

A Guide To JSLint Messages

This article is one of a series on the error and warning messages produced by JSLint.

JavaScript functions can be written as a declaration or as expression, as in the following examples:

function a(){} //function declaration
var a = function(){};  //function expression

The first line declares a function, and the second declares a variable. For the purposes of this discussion, we can think of the key word ‘function’ as having a similar purpose to the keyword ‘var’, namely, that it declares something (‘a’ in both cases).

Both are perfectly legitimate ways of declaring a function, as is the following:

var a = function(){alert("1";)};
a = function(){alert("2");};

All we are doing here is reassigning the variable ‘a’ with a different function expression. JSLint will not complain about this in the slightest, simply because there is nothing wrong with this. However, what if we substitute the first line above with a function declaration, JSLint starts complaining with ‘a’ is a function:

function a(){alert("1";)}; //JSLint error: 'a' is a function
a = function(){alert("2");};

Instead of ‘a’ being a ‘var’, it is a ‘function’, but in the second statement we attempt to use it as a ‘var’. In other words we are attempting to turn it from a function declaration to a  function expression.

You may find out that the interpreter is tolerant of this, but it is still indicative of something potentially problematic, and possibly not what was intended.

For more information on function declarations and function expressions, refer to this article at JavaScript, JavaScript. Related, and also of interest is this article on JavaScript Scoping and Hoisting.

A Guide To JSLint Messages

This article is one of a series on the error and warning messages produced by JSLint.

JSLint prompts you with this message when it encounters what it perceives to be a dangerous, or “bad” assignment. For example:

document.getElementById("text"+x) = function(){};

In the above code, we are calling a function, and then attempting to assign it a value. Clearly the case of document.getElementById() nonsense anyway, and will fail. It doesn’t shed any light as to how this sort of error might occur, so let us look an example with custom objects.

It is possible to create a function within a JavaScript object in many ways. The following demonstrates one such scenario:

var obj = { fn : function () {}};

No problems here. But what if we wanted an ad-hoc creation (possibly as part of some sort of desire to extend an existing object)? We might see something resembling the following:

var obj2 = {};
obj2.fn = function () {};

Again, no problem. However it is conceivable that we might encounter the following (entered, perhaps, by accident):

var obj2 = {};
obj2.fn() = function () {};

Do you spot the subtle difference? The developer has stipulated an extra set of brackets. It will certainly not what was intended, but has found its way into the code. When JSLint encounters this, will complain about a bad assignment.

But, in JavaScript, object members can also be referenced using the array/collection [] notation. Happily, JSLint is clever enough to spot this. So the following will yield the same error (along with another JSLint error [{a}] is better written in dot notation):

document["getElementById"]("test") = function(){};

A Guide To JSLint Messages

This article is one of a series on the error and warning messages produced by JSLint.

In JavaScript we can declare a function anonymously, and using a concept known as late-binding we can attach the event to an HTML object:

document.getElementById("control").onclick = function(){//code};

We can also conceive a situation whereby we can do this to multiple controls within a loop. Casting aside the capabilities of JavaScript libraries such as jQuery for the moment (we’ll examine jQuery  later), the code might look something like:

var x=0;
for(x = 1; x<4; x++){
    document.getElementById("text"+x).onclick = function(){
        alert("test");
    };
}

Herein lies the complaint of JSLint: “Don’t make functions within a loop.” In the above code, on every iteration of the loop we will evaluate the function. This is wasteful and unnecessary. It’s much better simply to store the function in a variable:

var x=0;
var f = function(){
    alert("test");
};

for(x = 1; x<4; x++){
    document.getElementById("but"+x).onclick = f;
}

For many cases this will be sufficient,  but the above ignores the frequent requirement to pass values to functions. So how can we do this?

Well, in the above example a parameter will be passed to the function automatically. This parameter will be the event object that represents the source event. From this object we can infer the event source (e.g. an HTML button), and from the event source, we can infer object data.

Consider the following code (See it work at this JSFiddle):

var x=0;
var f = function(evt){
    evt.target = evt.target ? evt.target : evt.srcElement;  //cross-browser event target retrieval
    alert(evt.target.getAttribute("data-info"));
};

for(x = 1; x<=3; x++){
    var objButton = document.getElementById("but"+x);
    objButton.setAttribute("data-info", x);  //set a 'data-'attribute
    objButton.onclick = f;
}

Here we bind the data (x) to the control using the setAttribute() function on the object. We can retrieve this by calling getAttribute on the event target when the event fires. Refer to the JavaScript kit event object for more information on JavaScript events.

Or, of course, we can disregard the event obejct altogther, and instead use the JavaScript this object (available at this slightly updated fiddle)

var x=0;
var f = function(evt){
    alert(this.getAttribute("data-info"));
};

for(x = 1; x<=3; x++){
    var objButton = document.getElementById("but"+x);
    objButton.setAttribute("data-info", x);
    objButton.onclick = f;
}

The JavaScript this object is discussed in more depth over at QuirksMode.org.

And what about jQuery? Well, this can actually hide this sort of problem from JSLint. Consider the following:

$("input:button").each(function () {
    $(this).click(function () {});
});

This slightly contrived example (contrived because we don’t need to call the .each() to bind for all elements in the collection) will pass a JSLint scan, and yet, still break the rule that it was trying to preserve. We are still evaluating a function for every call of .each(), but JSLint doesn’t (and can’t) know this .each() functions as a loop.

But, adopting the pattern above in the same manner will solve this problem.

A Guide To JSLint Messages

This article is one of a series on the error and warning messages produced by JSLint.

A programming convention that is frequently carried into JavaScript from other languages (often by C++ and C developers)  is the scoping of functionality within isolated blocks of code (i.e. between parentheses).

Take the following:

int y = 2;
{
    int x = 3+y;
    DoSomethingWith(x);
}

But JavaScript is less fussy about scoping, so the following will execute probably execute without complaint:

var y = 2;
{
   var x = 3;
}
alert(x+y); //alerts '5'

The use of the block here, therefore, is just extra noise. Its more characters to be written, read and transmitted. In addition to this, in some cases its contrary to the language specification. Consider the use of the ‘case’ statement:

var x = 0;
switch(x){
    case 0:{
            var y = 1;
            alert(y);
        }
}

Here we have added some parentheses to the ‘case’ block of code. In C, C++, this sort of convention is necessary. In JavaScript, it is not, so the following will work happily:

var x = 0;
switch(x){
    case 0:
        var y = 1;
        alert(y);
}

The first statement is contrary to the language specification. (Refer to the official EC5 Specification and the Mozilla JavaScript reference for more information). This reason alone is justification enough for JSLint to throw the error ‘Expected to see a statement and instead saw a block’, even before considering the extra noise the blocks create.

There is another potential argument against the use of (bogus) scoping blocks in this way. JavaScript also uses parentheses for objects and object literal declarations:

var y = {
    x:3,
    f:2
};

So, avoiding the specification of bogus scoped blocks will also make our code easier to read and subject to less confusion.

A Guide To JSLint Messages

This article is one of a series on the error and warning messages produced by JSLint.

With this message, JSLint is warning you of a potentially hazardous use of the decimal point. The following code will yield this error:

alert(.2);

Here. JSLint is picking out conventions that may be indicitive of some other problem in your code. It is also not making the assumption that every single JavaScript interpreter will handle this code correctly.

This is closely related to the message A trailing decimal point can be confused with a dot ‘{a}’

A Guide To JSLint Messages

This article is one of a series on the error and warning messages produced by JSLint.

I kept stumbling across this one when investigating the message A dot following a number can be confused with a decimal point. This particular message proved easier to produce than the aforementioned one.

With this message, JSLint is warning you of a potentially hazardous use of the decimal point. The following code will yield this error:

alert(2.);

Here. JSLint is picking out conventions that may be indicitive of some other problem in your code. It is also not making the assumption that every single JavaScript interpreter will handle this code correctly.

This is closely related to the message A leading decimal point can be confused with a dot ‘.{a}’

A Guide To JSLint Messages

This article is one of a series on the error and warning messages produced by JSLint.

This is a strange one, and took  some tracking down. Most attempts to bring about this message merely yielded another similar message: A trailing decimal point can be confused with a dot ‘{a}’.

Eventually I stumbled across it. So, what do you expect the following to yield?  (Readers should note that the space between the ’2′  and the ‘.x’ is intentional):

alert(2 .x);

Well, the answer is ‘undefined’.

Eh?

Things only appear to get stranger. Try this:

alert(2 .valueOf());

The alert here pops up with ’2′. Okay, so clearly it’s another way of writing the following…

alert(2.valueOf());

Right? Wrong! This merely yields a syntax error.

What’s going on here is best explained over at Stackoverflow: What’s going on with this rather peculiar JavaScript syntax?

A floating-point numeric constant must not have embedded spaces. Thus, ’2 .x’ is an expression calling for the constant ’2′ to be promoted to a Number object, and then the property called ‘x’ is examined. There isn’t one, of course, so the value is ’undefined’.

I can see why JSLint complains about it. The convention is so arcane that it’s probably not what the developer intended, and if they did then they really ought to have known better!

A Guide To JSLint Messages

This article is one of a series on the error and warning messages produced by JSLint.

It could be argued that this is one of the family of messages under Expected ‘{a}’ and instead saw ‘{b}’. One of my university professor referred to as ‘error 1′, because it was the single most common and hard-to-spot syntax issue he encountered. Although he was a C programmer by trade, the syntactic similarities between C and JavaScript have allowed the issue to exist in both languages.

Here is some problem code:

if (x=0){
    //do stuff
}

What it is, of course, missing is a comparison operator. We have, instead, the assignment operator ‘=’ where would really be expecting an equality operator ‘==’, or, even better an identity operator ‘===’. We can see it in action in this JSFiddle.

The above code will return ’0′ which resolves to ‘false’, and therefore the block of code is not executed. Where it is non-zero it is assumed to be true, and the code is executed. Regardless, the statement is broken, or indicative of some very poor code.

Refer to this article on JavaScript operators for more information on:

• arithmetic operators,
• relational operators,
• string operators,
• logical operators,
• bitwise operators, and
• a few others that don’t really fit into any category.

A Guide To JSLint Messages

This article is one of a series on the error and warning messages produced by JSLint.