A summary. Correctness: the primary objective. Code that does what it's supposed to, bug free. Readable: strive to write code that will be understandable by o

A summary. Correctness: the primary objective. Code that does what it's supposed to, bug free. Readable: strive to write code that will be understandable by others (and your future self). Review what you wrote for clarity and be your own critic. Idiomatic: Write code the way people in your community expect to read. Don't surprise them with your own quirky and clever conventions, when there are well established and perfectly acceptable ones already. Simple: Your code should do what it says it does directly, with no funky side-effects. Repetition is not always a sin, don't DRY things up just for the sake of it. Don't do too many things. Be parsimonious. Performant: be aware of RAM (a bit of a letdown, was expecting "code to data structures" advice). --- Author concludes with a few interesting take-away points. Some highlights (paraphrasing): - don't trust foolproof software engineering methodologies sold using a neat backronym. - words like "clean", "simple", and "readable" are as vague as "freedom", "justice", or "equality". - neat slogan like "don't repeat yourself" or "clean code" are moot. - correctness above all else. - tests only prove that the code can pass the test. - No info is better than bad info. No tests is better than bad tests. - all software has two types of bugs: those you've found and those you have yet to find. - we all want readable code, but we have different definitions of "readability". ...