Much of the behavior of JSLint is explained on the JSLint instructions page. I will refer to it as the JIP from now on.
Much of the behavior that is not explained by the JIP is explained by Code Conventions for the JavaScript Programming Language by Crockford. I will refer to it as the CCJPL from now on.
To go down the list:
1) Why does JSLint signal an error if you don't include "use strict";?
Because strict mode enforces many good practices; JSLint is all about enforcing good practices too, so naturally this is its behavior. Looking at what "use strict" enables helps clarify the matter. I'm simply going down the list of this blog post by Resig, so due credit is given there. I'm not commenting on everything it does because I'm not sure of exact reasoning from Crockford for every feature.
- Variables must be declared with
var before you can assign a value: this stops implicit globals from appearing. Global variables are considered by Crockford to be evil, and this helps eliminate globals you didn't explicitly set.
- It several restricts eval, which Crockford considers to be evil as per the JIP.
- It disables the
with statement. This is considered by Crockford to be harmful.
I only skipped out on two features of strict mode: the delete statement's behavior being modified and overwriting the arguments variable. I don't know if Crockford agrees or disagrees with these two things, but given that he helped create the ECMAScript 5 standard, I would lean towards agree.
2) Why should variable declarations within a function be done using a single var?
First, any variable that is defined without being declared by var is implicitly global, which, according to the JIP, can "mask misspelled names and other problems." So, that is the reasoning requiring var.
As for requiring one var, all variable declarations are hoisted to the top of their scope by the JavaScript engine automatically, so my only guess is that Crockford wishes for the developer to be acutely aware of this behavior. Past that, it's probably a matter of style. Which do you prefer between the two following pieces of code:
var a, b, c;
or
var a; var b; var c;
My guess is that Crockford thinks the multiple vars are ugly there. I agree with him on that point.
Ironically, as per the CCJPL, he actually suggests having all of the variable declarations on different lines with associated comments. JSLint disagrees with him in this regard!
3) Why do we need to put a space between function and () in function ()?
This applies only to anonymous functions. As per the CCJPL, it is because:
If a function literal is anonymous, there should be one space between
the word function and the ( (left parenthesis). If the space is
omited, then it can appear that the function's name is function, which
is an incorrect reading.
When I was in the thick of learning JavaScript, I religiously began following Crockford's conventions... but the logical part of me says that if you have code that names a function function, it's probably in dire need of reworking anyways. (Not to mention that in JavaScript, it's a SyntaxError because function is a keyword.)
4) Why can't we use continue?
To quote the CCJPL:
It tends to obscure the control flow of the function.
Not exactly an elaborate answer, but I've seen arguments on the internet comparing it to goto. Take that as you will.
5) What is wrong with ++ and --?
As is said on the JIP:
The ++ (increment) and -- (decrement) operators have been known to
contribute to bad code by encouraging excessive trickiness. They are
second only to faulty architecture in enabling to viruses and other
security menaces. Also, preincrement/postincrement confusion can
produce off-by-one errors that are extremely difficult to diagnose.
6) Why can't we use the comma operator , (except in the initialisation and incrementation parts of the for statement)?
Another elaborate explanation from the JIP:
The comma operator can lead to excessively tricky expressions. It can
also mask some programming errors.
This is a real shame, because as the blog post you linked shows, the comma operator can really increase the clarity of code in some situations.
You will notice a common underlying theme throughout many of Crockford's conventions: understandable, readable code. This is just another example of that. Many conventions are centered around denying access to 'tricky' expressions.
But I think the real word I'd use to describe some of these expressions would be 'terse' -- which is not necessarily a bad thing, per se, but it can be evil if used wrongly. Crockford's conventions sometimes try to smash wrongly-used-terseness by removing some of the tools these expressions use, even if they have legitimate uses in some contexts.
7) Why should every single statement end with ;?
To quote the JIP again:
JavaScript uses a C-like syntax which requires the use of semicolons
to delimit certain statements. JavaScript attempts to make those
semicolons optional with a semicolon insertion mechanism. This is
dangerous because it can mask errors.
Like C, JavaScript has ++ and -- and ( operators which can be prefixes
or suffixes. The disambiguation is done by the semicolon.
Usually I find the 'can mask errors' part of Crockford's explanations to be rather broad and vague, but semicolon insertion is really one area where I can agree wholeheartedly. It's easier to use explicit semicolons after every statement than risk narrowing the dangerous waters of semicolon insertion.
Here is a classic example of semicolon insertion gone wrong from the Wikipedia page on JavaScript Syntax:
return
a + b;
// Returns undefined. Treated as:
// return;
// a + b;
And if you use an object literal like the code from this blog post (a fairly common style of braces), then it can mess you up too:
function shoeFactory() {
return // <--- semicolon inserted here
{
shoeSize: 48
};
}
var shoe = shoeFactory();
console.log(shoe); // undefined
Another example from the above Wikipedia article:
a = b + c
(d + e).foo()
// Treated as:
// a = b + c(d + e).foo();
I've never really been perturbed by adding explicit semicolons, either. They come to me very naturally when writing almost any code. In fact, I often catch myself putting semicolons in Python even though they're not necessary.
In this case, I agree pretty wholeheartedly with Crockford. I think one debugging session concerning semicolon insertion would probably convince most people that it would be easier just to place them in the code.
