Clean Code : Chapter 1

Image source

The author starts off (at this point repeating) by setting expectation that this will be a book filled with lots of code and it will make the reader a better programmer.

The author mocks at the notion of a future wherein all code would be auto-generated from specifications. I was very impressed by one of his statements wherein he says

    “code represents the details of the requirements”.

I think its very true. What we sometimes in our conversations on functional design brush off as “implementation detail” is actually THE specification realized as code. It is a very interesting perspective. But his next statement is a bit too opinionated and a bit incorrect I felt- he says 

“specifying requirements in such detail that a machine can execute them is programming”.

I don't think that's true. A machine just needs 1s and 0s to execute instructions, it is us (humans) who need code, be it high-level, low-level or assembly to maintain the software and build on it.                                                      

Next, the author in many different ways discusses the consequences of bad code. He mentions the ill fate of a software company that had created a massively popular product but could not maintain it well i.e. keep bugs under control and continue to innovate. A situation most of us would have run into is needing to make a feature, but using hacks. More often, we tend to forget about this mess until the next person needs to deal with it. The author talks about how feature development is quick at the start of a project and how it limps along as code grows and finally comes to a grinding halt. Management decisions to throw more people at the problem just does not help the cause

Eventually, it is the programmer who should take blame for bad code irrelevant of what “forced” him/her to do that. It is on the person who writes code to set expectations with business/management/marketing etc that innovation/features will happen only if clean code happens.

The author then acknowledges that it takes time, hard work and practice for a programmer to acquire the ability to write clean code / refactor bad code.

The author then presents the view-points of a few experienced and respected programmers and their take on clean code. Here is the bullet list of things from the different folk.

Clean code is:

- readable — minimal explicitly defined dependencies, clear concise API

- straightforward

- optimal enough

- modular and each module does one thing well

- has error handling and tests

Finally the author wraps up by saying that the rest of the book basically is his version of what clean code is. He encourages the reader to understand the perspectives and opinions presented but to also form their own/explore other schools of thought as time passes.

Lastly he ends with this really nice quote

“Leave the campground cleaner than you found it”