Because of the way our brains work we don’t always look at our own interests. Head and gut are two systems we depend on heavily but false premises lead to false conclusions.
Visual Processing: The evolutionary process taught us that it is more important to be accurate than fast. Your brain is lying to you all the time.
Computer programs are the most complicated things people make. The leaps in abstraction come slowly. Programming requires perfection. Failures are your fault.
We release code in an unfinished state hoping defects will be discovered before anyone really catches on.
We’re making all of this complicated stuff with the brains of hunters and gatherers. Nothing in our evolutionary experience has prepared us for programming and it’s a miracle we can do it at all.
Programming uses the head and the gut.
We are constantly switching point of view until the program appears. We’re not sure how this switching process really works. The steps can’t be easily codified.
Pure analysis is not sufficient to code, we must rely heavily on the gut. Douglas Crockford has no evidence to support that statement but his gut tells him it’s true.
Warning: jslint will hurt your feelings. Follow its advice and your programs will get better.
How many man centuries have been wasted arguing whether the curly braces go on the left or the right?
“Be consistent” means “everyone should do it like I do.”
Switch statement: The Fall-through Hazard
We spend most of our time staring into the abyss rather than power typing. When we figure it out we experience euphoria and forget to do a danger analysis. We need to document it and change the process so it doesn’t happen again.
“That hardly ever happens” is just another way of saying “it happens”.
The gut is really bad at numbers.
A good style can help produce better programs. Style should not be about personal preference or self expression. It should be about adding value to the program.
Romans used to write in all upper case with no spaces. Medieval copyists introduced lowercase, word breaks and punctuation. These innovations helped reduce the error rate. Good use of style can help reduce errors.
Programs must clearly communicate to people.
Use elements of good composition where applicable. For example, use a space after a comma, not before. Only depart from that if you have evidence that shows a significant payoff.
Parentheses are hanging off the end here like a pair of dog balls.
Focus on clarity for the user. Never rely on automatic semicolon insertion.
It’s not that with is not useful, it’s that there is never a case where it isn’t confusing. Confusion must be avoided.
Always use === never ==. === always does the right thing, == sometimes does the right thing.
Make your programs look like what they actually do.
Global variables are evil. Avoid global variables. When using global variables, be explicit. Use UPPER_CASE.
Global variables should be as rare as hens teeth and stick our like a sore thumb.
Forgetting new causes a constructor to clobber global variables without warning. If you forget to put new in front of a constructor you don’t get a warning. Constructor functions, and nothing else, should be named with InitialCaps to identify where new is being used.
Write in a way that clearly communicates your intent.
Don’t use x++. Use x+= 1.
Subtle difference between pre-increment and post-increment. It’s a subtle error because it’s only wrong for one instance. x++ != ++x.
Programming style is not about selecting features because they are liked, pretty, or familiar. Designing a programming style demands discipline.
The consequence of bad programming style is staring into the abyss of your editor trying to figure out why the code you wrote doesn’t work. Reducing the amount of time you spend in the abyss is the real win. Reduce time chasing down stupid errors.
Forms that can hide defects are considered defective.
Good style is good for your gut.