I’m currently working through a list of code book recommendations. Writing up short summaries helps me review what I’ve learned, anchor it more deeply, and increase chances that … I actually apply anything 😂. I’ll be sharing these in case it helps others 👍
Key takeaways from Clean Code by Robert C. Martin
✔️ Choose good names for everything. A good name is a lot better than using comments.
✔️ Try to feed functions as few parameters as possible. It makes it much easier for others to understand.
✔️ One function should do one thing. One level of abstraction per function.
✔️ Switch statements: can be tolerated once if they are used to create polymorphic objects, are hidden behind an inheritance relationship.
✔️ Comments don’t make up for bad code. Explain yourself in code, not in comments. TODO comments can be OK.
✔️ Formatting code is SUPER important 🤪 (apologies to my colleagues — yes I do know this and one day I’ll find a more accessible .erb formatter for VSCode, or better, email me if you find one!). Care about vertical and horizontal formatting.
✔️ Try and keep your variables private (reduce getters and setters to a minimum). That way no-one depends on them them you can change them on a whim.
✔️ We don’t want to expose the details of our data. We do want to express our data in abstract terms. Really think about how to represent the data that an object contains. Blindly adding getters and setters is not it. Objects should hide their data and expose operations. They should not expose their internal structure through accessors. Objects expose behaviour and hide data. Data structures expose data and have no significant behaviour.
🔹 TESTS
✔️ Write tests before you write code. Test code is just as important as production code. It must be kept as clean as production code.Tests must be readable. Only have one assert per test.
✔️ Tests should follow the F.I.R.S.T. rule: Fast, Independent, Repeatable in any environment (prod, dev etc), Boolean output (y/n), timely (written just before the production code).
✔️ If you let tests rot, your code will rot.
🔹 CLASSES
✔️ Classes should begin with a list of variables. Try and keep variables and functions private. Classes should be small. The name of a class should describe its responsibilities. If this can’t be done, then the class is probably too big. We want our systems to be composed of many small classes, not a few large ones. Each class encapsulates a single responsibility and collaborates with a few others to achieve the desired behaviour.
✔️ Structure your system so that when (not if. When.) you need to update it or change features you can achieve this by extending code, rather than changing code.
🔹 SYSTEMS
✔️ Intent should always be clear. Systems must be clean too. It’s a myth that we can get systems right the first time. We should only implement today’s stories… then refactor and expand the system to implement new stories tomorrow. Start with a village, then grow to a then, then grow to a city. This is why need code that can be refactored with ease.
🔹 DESIGN
✔️ A design is simple if it meets these rules:
- Runs and completes all the tests (to confirm the system works as intended)
- Contains no duplication (once all the tests run we refactor and remove duplication)
- Expresses the intent of the programmer.
🔹 CONCURRENCY
✔️ Concurrency helps us decouple what gets done from when it gets done. This can improve throughput and structure of an application. The moment we have many users it’s likely we’ll need to serve them concurrently. Bit concurrency is hard. Once multiple threads and shared data come into play things get hairy.
(There are more detailed top tips on getting concurrency right, but skipping these for the purpose of this summary).
🔹 SUCCESSIVE REFINEMENT
✔️ Don’t stop working on your code once the program works. This is professional suicide. Its unprofessional.You must refactor it, improve the bad and broken bits within it, ideally immediately once the code works. Never let the rot get started.
🔹 SMELLS AND HEURISTICS
✔️ This chapter takes Martin Fowler’s Refactoring book’s list of code smells, lists them and adds a few additional ones. There’s about 30–40 so I won’t list them all. However some of the takeaways I’ll be trying and implement from my end include:
- Prefer polymorphism over if/else and switch statements
- Avoid negative conditionals
- Functions should do 1 thing
- Functions should descent only 1 level of abstraction
- Keep configurable data at high levels
- Choose descriptive names
- Use a test coverage tool
