Hello! I’m Shanice, a Software Engineer who’s a self-described advocate for diversity in tech, in more ways than one. Here I'll share a recap of my notes of Tidy First by Kent Beck.
The main takeaway I learned from the book was the importance of communication; from code to programmer and between programmers. Well-written code can be self-documenting, maintainable, and explicit, which allows for changes to the code structure without the risk of altering the code logic. When the code effectively communicates what it’s doing, it lowers the barrier of entry for cross-functional understanding, minimizes context switching, and increases accessibility and confidence for contributors. Code readers often include not only the original programmer but also engineers, program managers, QA engineers, designers, and future contributors. That's why dedicating time to tidying code through small, structural changes is a low-effort way to ensure that future behavior changes are set up for success.
Some tidying techniques I’ve highlighted are:
Separate PRs of behavior changes and tidying. I'm guilty of including refactors and tidying tasks in the same PR of large application logic updates. If it makes more sense for the reviewer, separate behavior changes. With smaller tidying PRs or commits, they can be reviewed on their own since the main objective is to simplify the codebase for future application logic.
Delete dead code. Or "kill your darlings" as writers would say. It's the process of eliminating code from the codebase that's no longer in use. Admittedly, I have a hard time letting go of the code I've written, but there is just as much value in the amount of code you write as the amount of code you remove. When you're debating whether a piece of code should be removed, think of it this way: Is this code serving a purpose? Will the removal affect anything else in the codebase? Is it worth saving even for documentation's sake? If you're worried about the case of needing the code in the future, luckily version control exists and you can recover the code when it's needed again.
Normalize symmetries. If you find patterns in the codebase, use them as the standard approach to increase consistency for contributors. Convert to fewer variants of code that accomplish similar methods, but are written in different ways.
Exit functions early with guard clauses. This would remove the need for nested conditionals that get messy or difficult to read over time. Implement guard clauses or a pre-condition check that'll return a statement or exception immediately in a program.
Extract helpers when possible. Discover repetitive behaviors that constantly reappear throughout your codebase? Turn the code into a helper function to reference where needed.
These are just a few tidying tips I've learned and hope to apply in my day-to-day coding in my personal projects and professional work. There are benefits to the tidying approach.. within context. Tidying can be done before, while, or after behavior changes. You can tidy everything and not tidy at all, but I'd like to find a happy medium. It's a balancing act that needs to be discussed within a team of people interacting with the codebase. As the table of contents of the book suggests, the key to tidying is to communicate the "what?", "when?", and "why?", so you can focus on what matters: changing code with ease.
If you have any tidying tips, share them in the comments section!
Top comments (0)