Clean Code: A Handbook of Agile Software Craftsmanship’s summary Chapter 1 : Clean Code

Author Robert C. Martin begins the contents in his book by claiming that:

“Writing clean code is what you must do in order to call yourself professional. There is no reasonable excuse for doing anything less than your best”

Below are some of the points that James O. Coplien makes in Foreword:

1. Attention to details is critical foundation of professionalism than is any grand vision
2. 80 percent of work in software is maintenance.An ounce of prevention is worth a pound of cure. Software should be written by focusing in maintenance rather than on production.
3. Making your code readable is as important as making it executable
4. He applauds Japanese worldview that understands the crucial value of consistent everyday work and apply that viewpoint in software development to emphasize the value of code simplicity, daily care and consistency.
5. He points out Danish wisdom that advises honesty in small things is equally as important as paying attention to small things. He advises us to be honest to the code, our colleagues about state of code and most importantly to be honest with ourselves about our code. He claims that neither architecture nor clean code insist on perfection, only on honesty and doing the best we can.

Introduction has some important points :

1. This is not a “feel good” book. There are two parts of learning craftsmanship : knowledge and work . Having only the knowledge of clean code is not going to work, it requires hard work to apply that knowledge(sounds Cliche but worth mentioning)
2. Brutal and cruel feedbacks from reviewers pushed him to make necessary improvements. My free advice : next time ask your manager or coworker for cruel feedback and promise yourself not to take it personally 😁.

Finally, Chapter 1: Clean Code

Uncle Bob starts the chapter by taking our attention to “whys of reading this book”. The “whys” is because first we are programmers and second we want to be a better programmer. He claims that by the time we finish the book we should be able to differentiate between good code and bad code as well as transform bad code into good code.

Following are some of the important points in chapter one:

1. There Will Be Code: He reasons against those who believes that soon all code will be generated instead of written. He argues that we will never get rid of code because code represents the details of requirements. However, some code can be abstracted away.
2. Bad Code: Gives an example of killer app that ran out of business because company rushed the product to market and did not pay much attention to code maintenance.He does not support the idea of working messy code over maintainable code. I had recently read one of the 14 principles of Amazon i.e “Bias for Action” which focus on the value of speed in business . Amazon believes that many actions and decisions are reversible and do not need extensive study. They value calculated risk taking. I want to understand what Uncle Bob think of this Amazon principle!
3. The Total Cost of Owning a Mess: Even-though team can move very fast at the beginning of the project with messy code, they will find themselves at snail’s pace after two to three years. Design intent get lost over time.When mess builds over time, the productivity of the team continues to decrease.
4. Attitude : It is the responsibility of a programmer to defend his/her code. He/she must be honest with manager regarding the quality of code even if that means going against manager’s decision.
5. The Primal Conundrum: Uncle Bob says “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.”
6. The Art of Clean Code? : Uncle Bob wants us to believe that messy code is a significant impediment. Writing clean code requires disciplined approach that makes use of little techniques with the sense of “cleanliness” thereby transforming bad code into clean code. “code-sense” is the key, some are born with it and some need to learn it. The one with “code-sense” can tell action steps required to transform messy code!

Definition of Clean Code :

Bjarne Stroustrup: Clean code is focused. Bad code has muddled intent and ambiguity of purpose. Clean code is elegant and efficient. Error handling should be complete which follows the principles of paying attention to details.

Grady Booch: “Clean code is simple and direct. Clean code reads like well-written prose. Clean code never obscures the designer’s intent but rather is full of crisp abstractions and straightforward lines of control”

“Big” Dave Thomas: “Clean code can be read, and enhanced by a developer other than its original author. It has unit and acceptance tests. It has meaningful names. It provides one way rather than many ways of doing one thing. It has minimal dependencies, which are explicitly defined, and provides a clear and minimal API. Code should be literate since depending on the language, not all necessary information can be expresses clearly in code alone.”

Michael Feathers: Out of all qualities he believes that clean code should look like as if it is written by someone who cares. Uncle Bob reemphasizes that writing code with great care is the main goal of his book and thinks that probably the appropriate subtitle of the book could have been How to Care for Code.

Ron Jeffries: In the order of priority simple code according to him is the one that:

1. Runs all the tests

2. Contains no duplication

3. Expresses all the design ideas that are in the system

4.Minimizes the number of entities such as classes, methods, functions, and the like.

Ward Cunningham: “You know you are working on clean code when each routine you read turns out to be pretty much what you expected. You can call it beautiful code when the code also makes it look like the language was made for the problem”

School of Thought: How do uncle Bob defines clean code ?

We have entire book that will tell us in hideous details what Uncle Bob and his compatriots think about clean code!

Conclusion :

Uncle Bob wants us to think of us as authors and take responsibility for communicating our code well to readers. The ratio of time spent reading vs writing code is 10:1, hence reading of code should be made easier even if it makes writing harder.

“Books on art don’t promise to make you an artist” therefore practice, practice and practice. You don’t learn to ride a bike by reading a book on how to ride a bike ? Do you ? If so , I want to see you fall from that bike :D

Also, did you know that you could clap 50 times if you really really like the article and value my hard work!

Chapter 2 summary is here.