On 13 January, 2012, I saw Javascript expert Douglas Crockford deliver a talk titled “Programming Style and Your Brain” on the campus of the University of Pennsylvania. The brain portion of the talk (which Mr Crockford said borrowed heavily from Daniel Kahneman’s book Thinking, Fast and Slow
For example, programmers have been arguing since the 1970s about the placement of curly braces. Some people prefer:
if ( true ) {
doSomething();
}
Others prefer:
if ( true )
{
doSomething();
}
Crockford says that if the compiler treats these 2 forms as equivalent, then there is really no difference (so long as you are consistent). These are Gut decisions. However, people will use their Head to try to rationalize their Gut decisions and come up with some ridiculous rationalizations.
OK, fine. What does that mean in practical terms, i.e. writing code?
Crockford’s advice is:
Prefer forms that are error-resistant.
This is aligned closely with my own advice:
Prefer explicit forms to implicit forms.
One of Crockford’s illustrations (which I have not verified but sounds plausible enough) is that the space character was introduced into Latin writing after the prior practice of running all the words together led to ambiguity and transcription errors. The space characters made the text more explicit, and therefore less prone to transcription error.
Here are 3 of the Javascript examples Crockford provided during his talk:
Curly Braces & Conditional Statements and Loops
In Javascript, a conditional statement or a loop containing only one statement can be written without curly braces:
if ( condition ) doSomething();
This form is error-prone. Include the curly braces:
if ( condition ) {
doSomething();
}
Some people might complain and say that this is less concise and requires extra typing. Crockford’s response was: less concise is better, and the majority of the time it takes to write a program is in thinking, not typing. If adding a few characters is slowing you down, you either need to take a typing class or spend more time thinking!
Double-Equals versus Triple-Equals
Crockford said that using double-equals (==) to compare objects is always a bad idea because it does implicit type conversion. For example:
var n = 5;
n == 5; //true
n == "5"; // true
n === "5"; // false
n === 5; // true
The triple-equals also helps developers know that a number is expected, not a character or other data type.
As Crockford emphasized:
If a feature is sometimes problematic, and a more reliable feature exists, use it!
Some people might try to justify the use of implicit type conversion: “But I’m doing it intentionally!” Crockford said that relying on implicit type conversion means you don’t know what you’re doing.
Incrementing Values
Crockford said he never uses the prefix or postfix ++ operator, because many people don’t understand the difference and it can lead to confusion. For example:
var x = 5;
var y = x++; // y is now 5 and x is 6
var z = ++x; // z is now 7 and x is 7
x += 1; // x is now 8. This is Crockford's preferred method to increment a variable
Crockford provides several resources to help people write better, more error-resistant Javascript:
- Code Conventions for the JavaScript programming language
- JSLint, which alerts you to errors in your code or error-prone code (“JSLint will hurt your feelings”)
- JSMin, which “minifies” (removes unnecessary characters) from Javascript files. This should be largely unnecessary if your web server uses Gzip compression.