Name

A Philosophy of Software Design

Author

John Ousterhout

Date Published

2018-04-10

Date Read

2024-12-12

Bookshelves

Have Read

Genres

Computers

Software

Summary of design principles

1. Complexity is incremental; you have to sweat the small stuff (see p. 11)
2. Working code isn’t enough (see p. 14).
3. Make continual small investments to improve the system design (see p. 15).
4. Modules should be deep (see p. 23).
5. Interfaces should be designed to make the most common usage as simple as possible (see p.27).
6. It’s more important for a module to have a simple interface than a simple implementation (see pp. 61, 74).
7. General-purpose modules are deeper (see p. 39).
8. Separate general-purpose and special purpose code (see pp. 45, 68).
9. Different layers should have different abstractions (see p. 51).
10. Pull complexity downward (see p. 61).
11. Define errors out of existence (see p. 81).
12. Design it twice (see p. 91).
13. Comments should describe things that are not obvious from the code (see p. 101).
14. Software should be designed for ease of reading, not ease of writing (see p. 151).
15. The increments of software development should be abstractions, not features (see p. 156).
16. Separate what matters from what doesn’t matter and emphasize the things that matter (see p. 171).

Summary of red flags

• Shallow module: the interface for a class or method isn’t much simpler than its implementation (see pp. 25, 110).
• Information leakage:
a design decision is reflected in multiple modules (see p. 31).
• Temporal decomposition: the code structure is based on the order operations are executed, not on information hiding (see p. 32).
• Overexposure: An API forces callers to be aware of rarely used features to use commonly used features (see p. 36).
• Pass-through method: a method does almost nothing except pass its arguments to another method with a similar signature (see p. 36).
• Repetition: a nontrivial piece of code is repeated over and over (see p. 68).
• Special-general mixture: special-purpose code is not cleanly separated from general purpose code (see p. 71).
• Conjoined methods: two methods have so many dependencies that its hard to understand the implementation of the other (see p. 75).
• Comment repeat code: all of the information in a comment is immediately obvious from the code next to the comment (see p. 104).
• Implementation documentation contaminates interface: an interface comment describes implementation details not needed by users of the thing being documented (see p. 114).
• Vague name: the name of the variable or method is so imprecise that it doesn’t convey much useful information (see p. 123).
• Hard to pick name: it is difficult to come up with a precise and intuitive name for an entity (see p. 125).
• Hard to describe: to be complete, the documentation for a variable or method must be long (see p. 133).
• Nonobvious code: the behavior or meaning of a piece of code cannot be understood easily (see p. 150).