Book Summary: Tidy First? by Kent Beck

Kent Beck’s Tidy First? is a concise and engaging read, outlining several “tidyings”–small code improvements–that make software easier to understand and more adaptable to future changes. He emphasizes that “software design enables change” and that even small design improvements can facilitate smoother modifications.

Key tidyings discussed in Part I include:

• Guard Clauses: Within routines, move “guards” or “preconditions” to the top and return early. Avoid too many guard clauses within a routine. Avoid nested conditionals.
• Dead Code: Delete code that isn’t executed.
• Normalize Symmetries: Avoid interchanging patterns that accomplish the same behavior. Pick one way and stick with it. Find commonalities and separate the different parts from the identical parts.
• New Interface, Old Implementation: Introduce new interfaces while maintaining existing implementations, easing future transitions. This also extends to helpers that would make future changes easier.
• Reading Order: Organize code in the order that makes sense for the reader.
• Cohesion Order: Reorder code so similar elements are adjacent.
• Move Declaration and Initialization Together: Keep variable declarations close to their initialization logic to simplify code comprehension.
• Explaining Variables & Constants: Use clear, descriptive variable names and constants to document the purpose of values and avoid “magic numbers.”
• Explicit Parameters: Design routines to accept explicit parameters rather than generic objects for clarity and specificity.
• Chunk Statements: Break up code into logical sections with line breaks, much like paragraphs in writing.
• Extract Helper: Move code inside a routine that has an obvious, limited purpose to a helper function.
• One Pile: Don’t be afraid to inline code into “one pile” to enable subsequent tidyings.
• Explaining & Deleting Comments: Use comments wisely—keep explanatory ones and remove redundant or outdated ones.

In Part II, Beck delves into the mechanics of tidying, encouraging frequent, incremental improvements and advising that tidyings be separated from behavior changes. He even suggests experimenting with skipping code reviews for tidying PRs, noting that most decisions are reversible. Beck stresses the importance of modern IDEs that support automatic refactoring, remarking: “It is the 21st century, after all.” The philosophy here favors small, cohesive changes to reduce complexity and enhance focus.

Part III explores the theory behind software design, leaving the reader with thought-provoking ideas:

• Cost(software) ~= coupling: To reduce software cost, coupling must be minimized. However, decoupling comes at a price, and Beck draws parallels to the options markets, suggesting that the design we invest in today gives us the “option” to implement changes more easily in the future.
• Software hierarchy: Tokens –> Expressions –> Statements –> Functions –> Objects/Modules –> Systems.
• Key relationships in software design: Invokes, Publishes, Listens, Refers.
• Software engineers’ fundamental actions: Create and delete elements; create and delete relationships; and, increase the benefit of a relationship