Author: Robert Cecil Martin
Buy: Book Depository
It's good that I am writing this summing up a bit later than when I actually read the book, as like this I can write down what I actually remember from it - the key things that really changed me as a developer.
- TDD, TDD, TDD...
- Comments are generaly a smell, they are trying to make poorly written code readable.
- Private APIs (functions or methods) can have long and descriptive names.
- Naming is key - always try to use the same words for the same thing.
- Keep functions as small as possible.
- Keep your files and modules small.
- Treat your tests as they were production code.
Truth can only be found in once place - the code.
So if you want to go fast, if you want to get done quickly, if you want your code to be easy to write, make it easy to read.
Of course bad code can be cleaned up. But it's expensive.
Clean code always looks like it was written by someone who cares.
When you see commented-out code: delete it.
In fact wrapping 3rd party APIs is a best practice. When you wrap a 3rd party API you minimize your dependencies upon it.
If we all checked in our code a little cleaner than we checked it out, the code simply could not rot.
Because the ratio of reading code compared to writing it is so high, we want the reading of code to be easy, even if it makes writing harder. Of course there is no way of writing code without reading it, so making it easier to read makes it easier to write.
To write clean code you must first write dirty code and then clean it.
The majority of the cost of a software project is long-term maintenance. In order to minimize the defects as we introduce a change, it's critical for us to be able to understand what the system does.