I'm currently reading Clean Code by Robert C Martin. Here are some of my takeaways, chapter by chapter.
There will be code
Essentially, no matter how sophisticated software applications become, there is a layer of abstraction that cannot be achieved without human intervention.
The folks who think that code will one day disappear are like mathematicians who hope one day to discover a mathematics that does not have to be formal. They are hoping that one day we will discover a way to create machines that can do what we want rather than what we say. These machines will have to be able to understand us so well that they can translate vaguely specified needs into perfectly executing programs that precisely meet those needs.
Page 2
Bad Code
- Bad code has the potential to bring a project down.
- We wade through bad code: it impedes our progress, and changing it is a struggle.
- Bad code rots faster than clean code.
The total cost of owning a mess
- As mess increases, team productivity decreases.
- Redesigning doesn't solve the problem, it just adds to it.
- The new system has to replicate the old system, keeping up with any changes.
- By the time the system is near to complete, it's potentially so messy that it needs a redesign as well.
- The mess of bad code is your fault.
- Non-technical stakeholders look to you for the information required to make promises and commitments.
- Even when we're not asked, we should forthright with our opinions.
- It's unprofessional to bend to the will of stakeholders who don't understand the risk of making messes.
Schools of thought
- No school of thought is correct.
- Different schools evolve from disagreements with existing forms.
- One doesn't have to accept the truth of different schools of thought.
- One should see, and respect, the other's point of view.
We are authors
- We are writers of literature.
- The main purpose of our code is to be read.
- The majority of our time spent on a program is consumed by reading.
The boy scout rule
- Leave the campground cleaner than you found it.
- Don't submit new code without first cleaning up the existing code.
- Ensure that every submission not only delivers the requested feature, but also improves the underlying system specification.
Bibliography
- Implementation Patterns, Kent Beck, Addison Wesley, 2007.
- Literate Programming, Donald E Knuth, Centre for the Study of Language and Information, Leland Stanford Junior University, 1992.
Top comments (2)
I really like the The boy scout rule I first heard it from Matias from FunFunFunction on youtube and it stuck with me since. 1% improvement a day equates to a lot improvement over the years!!!
Yeah it's really relevant to software design isn't it?
As I was reading this part of the chapter I found myself thinking of a habit I've developed over the years, when touching a file.
It can add a bit of noise to diffs, but over time it becomes less and less.