Chapters

• Introduction

  Exploring the goals of code beyond specification.

• Recipe

  Programs should read like a recipe. Start at the top, and line by line work your way down. Error conditions should be indented to indicate they are obviously error cases.

• State

  Avoid changing the state of variables. Limit the scope of variables as much as possible.

• New

  New objects or data structures must be constructed by objects or functions dedicated to that purpose, and not mixed into the objects or functions that perform the primary work of the application.

• Polymorphism

  Polymorphism is the most effective way to make composable pieces that build into a flexible system. Organize code to leverage the polymorphism of the language.

• If

  Conditional logic complicates programs, and is often a mistake. Use polymorphism and program structure to avoid the use of unnecessary if statements.

• Naming

  Names should aspire to create the correct semantic map in the reader’s mind with as few characters as possible. Names must be as consistent as possible.

• Documentation

  Documentation in code should focus on how to use the code correctly, or why odd code exists, but avoid detailing exactly what the code is doing.

• Unit Testing

  Unit tests should focus exclusively either on ensuring complex code operates correctly, or that high-level contracts (APIs) are adhered to. Avoid directly testing simple internal functions whose implementation may change.

• Refactoring

  Use refactoring as a tool to learn about a codebase, and to slowly improve that codebase. Do not be afraid to begin refactoring, and do not be afraid to abandon a refactor.

• Conclusion

  Unless he is certain of doing as well [as the masters], he will probably do best to follow the rules.

• Cheat Sheet

  Single page of rules, tips, guidelines, and more.