Chapter 1 : What is Clean Code — Robert C Martin
The following is the summary and excerpts and my opinions on Chapter 1 of Robert C Martin’s Clean Code. None of the images in the blog is my own.
Robert C Martin ponders upon how many people think that writing code will become obsolete. However he claims that it simply is not true.
With the rise in AI no one at this point knows who will and will not be redundant.
Next he goes on to explain what bad code is. Then he talks about a preface of a book by Kent Beck’s.
I was recently reading the preface to Kent Beck’s book Implementation Patterns. 1 He says, “. . . this book is based on a rather fragile premise: that good code matters. . . .” A fragile premise? I disagree! I think that premise is one of the most robust, supported, and overloaded of all the premises in our craft (and I think Kent knows it). We know good code matters because we’ve had to deal for so long with its lack. — Robert C Martin
The moment developers start writing messy code thinking that they will clean up later is the point when problem starts creeping in the codebase. Hence it is important for developers to practice writing clean code until it becomes the first nature as it ensures that mess isn’t created in the first place.
Cost of messy code in the long run
Robert Martin points out that writing messy code creates technical debt in the long run.
I got an opportunity to work for a company which grew more than 50 folds in a matter of 5 years. The marketing team had succeeded in creating a good brand name. However because of exponential growth there was a huge technical debt.
The company initially wrote the entire software as one monolith. As the company grew it became apparent that they had to move to modular and scalable micro services.
The company slowly started breaking the monolith and writing micro services. Because of rapid expansion new features had to be added to both outdated monolith and new micro services. This doubled up the company’s daily maintenance and development cost.
Also because more than 300 developers worked in the monolith, it broke more often than not. A new feature that took 3 days to build actually took more than a week because of build failures.
Overtime technical debt creeps over the software reducing productivity and increasing development complexity.
What should programmers attitude be ?
Programmers should be responsible for making good estimates by properly communicating with all stakeholders to make sure that code isn’t messy. Sometimes writing bad code may seem to speed up development however bad code always slows down software lifecycle in the longer run.
It’s is crucial to have an attitude to defend code from all stakeholders. It may sometimes mean putting up a tough front while communicating with project managers or marketing department. Programmers have to do whatever it takes to ensure that their code remains clean.
PROFESSIONALS HAVE THEIR SAY ON WHAT CLEAN CODE IS
Robert has included opinions of well known tech professionals to describe what clean code is. I quite like this section :).
Here’s what different tech professionals think clean code is
“I like my code to be elegant and efficient. The logic should be straightforward to make it hard for bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy, and performance close to optimal so as not to tempt people to make the code messy with unprincipled optimizations. Clean code does one thing well.” — Bjarne Stroustrup
Code should be easy to read and should be like a piece of art that leaves you feeling good when you take a look at it.
Bad code tries to do too much, it has muddled intent and ambiguity of purpose. Clean code is focused. Each function, each class, each module exposes a single-minded attitude that remains entirely undistracted, and unpolluted, by the surrounding details[P]
“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.” — Grady Booch
Like a good novel, clean code should clearly expose the tensions in the problem to be solved. Our code should be matter-of-fact as opposed to speculative. It should contain only what is necessary. [P]
“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 for 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 expressed clearly in code alone.” — Dave Thomas
Clean code makes it easy for others to enhance it , has enough test coverages, is minimal and readable
“I could list all of the qualities that I notice in clean code, but there is one overarching quality that leads to all of them. Clean code always looks like it was written by someone who cares. There is nothing obvious that you can do to make it better. All of those things were thought about by the code’s author, and if you try to imagine improvements, you’re led back to where you are, sitting in appreciation of the code someone left for you — code left by someone who cares deeply about the craft.”- Micheal C Feathers
In recent years I begin, and nearly end, with Beck’s rules of simple code. In priority order, simple code:
Runs all the tests;
Contains no duplication;
Expresses all the design ideas that are in the system;
Minimizes the number of entities such as classes, methods, functions, and the like.
Reduced duplication, high expressiveness, and early building of simple abstractions.
That’s what makes clean code for me.
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.
- Ward Cunningham
He says that beautiful code makes the language look like it was made for the problem! So it’s our responsibility to make the language look simple! It is not the language that makes programs appear simple. It is the programmer that make the language appear simple!
How to write clean code
- Write readable code as it improves productivity. Reading the code should clearly explain what it does.
- Always leave the code a little bit cleaner as continuous improvement helps in maintenance of code.
- Practice writing clean code until it becomes your first nature.
