Let’s talk about writing Clean Code 🧽 I’ll go through each chapter of the book Clean Code: A Handbook of Agile Software Craftsmanship by Robert “Uncle Bob” Cecil Martin, and how each chapter applies to Swift.
A majority of the book is general and can be applied to any programming language, but a few concepts here and there don’t translate well. The book was originally written with all Java examples so some parts are completely irrelevant to Swift. Also be aware a few chapters make some bold statements! Take everything with a grain of salt.
The first chapter is all about the concept of clean code. What is it and how have others interpreted it.
It starts off describing bad code and its effects on developers. Bad code slows developer productivity and eventually could completely disrupt a team.
Imagine having to add a feature, but because of the poor shape of the code a one hour feature takes 20 hours.
[Refactor] later = never
LeBlanc’s Law
We then shift and discuss how did we get to this point of bad code? It’s the developer’s fault. Developers must clearly explain how certain features/deadlines can and can’t work in whatever situation. Think of it like this, you need your entire house painted, and you tell the painter they have one hour to complete the job. The painter will turn around and tell you that’s impossible. They are the expert in the situation, they should be directing how well they can meet the requirements. Not you, the non-expert (manager). The same concept holds true for developers and their deadlines.
The only way to make the deadline – the only way to go fast – is to keep the code as clean as possible at all times.
Clean Code, Chapter 1
Lastly we talk about what is clean code. Clean code is about writing code that is organized and easy to understand for yourself and for others on the team.
You won’t remember how you wrote something 3 months later, but if the code is clean, you should be able to easily read it and understand what’s going on.
Various excerpts are given from people in the industry about what clean code means to them. In no particular order, here’s what some people say:
- Pleasing to read
- Efficient
- Does one thing well
- Focused
- Readable
- Meaningful names
- Have unit tests
- Minimal dependencies
- Someone cared
- Pretty much what you expected
Stay tuned for the next chapter! Meaningful Names