Tidy First

2 min read

Here are my notes from Kent Beck's book "Tidy First". The author has a Substack of the same name here.

Structure your functions so that it clearly shows the preconditions to bear in mind.
Delete code that won't be executed. That's what version control is for.
Structure your code and functions consistently. Over time, the same problem may be solved differently, at different times, or by different people. Take the time to make this consistent.
Reorder the code in the file in the order in which a reader (remember, there are many readers for each writer) would prefer to encounter it.
When you come across code that separates the declaration (with a possible type) and initialization, it’s harder to read.
Create named constants for strings and numbers. This makes code more readable.
It’s common to see blocks of parameters passed in a map. This makes it hard to read and understand what data is required. It also opens up the horrific abuse of modifying the parameters for (implicit) use later.
Put blank lines before parts of code to separate logic.
Extract logic into helpers if a block of code has an obvious purpose but limited interaction with the rest of the code in the routine. Name it after the purpose.
If code has been split into tiny pieces and it's difficult to follow along, inline the code to one big pile, then tidy from there.
If you read code that takes you a while to understand, write a comment that explains it in the code for the next engineer.
When you see a comment that says exactly what the code says, remove it.

Cost: Will tidying make costs smaller, later, or less likely?
Revenue: Will tidying make revenue larger, sooner, or more likely?
Coupling: Will tidying make it so I need to change fewer elements?
Cohesion: Will tidying make it so the elements I need to change are in a smaller, more concentrated scope?

Salut, I'm Julia.