Notes from Douglas Crockford's "Programming Style & Your Brain"
Notes from Douglas Crockford's Programming Style & Your Brain in which he explicitly links the grammar and style in natural language to the grammar and style of programming languages, noting that strict rules can prevent ambiguities and errors from ever occurring.
Crockford made JSLint which aims to provide a level of opinion as to the "good parts" and "bad parts" of Javascript. He believes these types of tools should be far more opinionated, noting that if the C compiler forced curly bracket blocks to be standard that we'd have eliminated millions of hours of pointless debate as well as many potential ambiguities. In Javascript pushing blocks onto a new line results in a silent error given semicolons are automatically inserted.
Prefer forms that are resilient to error.
This is reinforced by a reflection on the switch statement, where the "fallthrough hazard" is almost never intended and causes a myriad of issues.
"That hardly ever happens" is another way of saying "It happens"
This comes to the first statement where I might disagree - though perhaps I'm thinking in terms of written expression versus programming expressions - that "Style should not be about personal preference and self expression". I do agree with his broader suggestion that "A good style can produce better programs" however.
Crockford then links this with natural language itself, noting that the Romans didn't use word breaks, punctuation, or lowercase. Medieval copyists introduced innovations such as lowercase, word breaks, and punctuation in order to reduce their error rates.
Good use of style can help reduce the occurrence of errors.
Crockford links to a summary of The Elements of Style that he produced and has likely influenced how he views programming languages as well.
- Programs must communicate clearly to people.
- Make your programs look like what they do.
- Write in a way that clearly communicates your intent.
- Designing a programming style demands discipline.
- Use elements of good composition where applicable (i.e. use a space after a comma, not before)
If there is a feature of a language that is sometimes problematic, and if it can be replaced with another feature that is more reliable, then always use the more reliable feature.
Finally, Crockford notes that "there will be bugs - do what you can to move the odds to your favor".