Ciao, I'm Julia.

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

Tidying Principles

• 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.

Things to consider before tidying

• 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?