Justifying Crockford claims

Question

I have read Crockford\'s JavaScript: The Good Parts and have used his validator JSLint. I am sometimes left wondering the justification behind his recommendations. Below is

Answer 1

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.

1. 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.
2. It several restricts eval, which Crockford considers to be evil as per the JIP.
3. 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.

Answer 2

You're right, Crockford doesn't very often substantiate his practices.

For example, defining vars somewhere other than the top of the scope is fine in my opinion, as long as you're aware. Javascript will hoist them to the top of the scope anyway. Furthermore, I think its actually beneficial, because you can easily pick out the initial value of a variable, all you need to do is look for the var.

I also think switch-case fallthroughs are very beneficial if you know how to use them. Particularly for writing something like a very complex state machine.

if and for's with a single statement following them, without curly braces is also fine. People have been writing C this way for decades.

If you're aware of what constitutes the end of a javascript statement, semicolons aren't necessary either. Semicolon insertion isn't random, it's not undecipherable contrary to popular belief.

Crockford is well known for trashing regex's...which is terrible. Very powerful (and fast) lexers can be written using regex's as the lexemes/rules/grammar/whathaveyou.

For the most part Crockford knows what he's talking about, but don't take his personal style as gospel. It's very unsubstantiated in my opinion. Some of the best javascript coders I've seen are in direct opposition to Crockford's style with regards to their code.

edit: I don't see why this question was closed. It can be discussed objectively, and is worth talking about.