Introduction to Clean Code

Hello all, I am creating a series of articles, each one a summery of some chapters of the book clean code by Robert C. Martin.

I have learnt a lot from this book, from writing a clean, well organized code, to having a different view of design patterns, separation of concerns and …I would love to share my experience with you by summarizing what I have learnt in each chapter.

In this article we are going to talk about What is clean code and How it will helps us in our everyday coding and creating applications.

So enough talking, let’s start

Introduction

The Book starts with an old Danish proverb saying :

“Honesty in small things is not a small thing”

and another well said quote :

“God is in the details”,said the architect Ludwig mies van der Rohe.

and it is what we are going to learn in this book, caring about every little piece of our code.

it is through practice in the small that professionals gain proficiency and trust for practice in the large.

In these days of Scrum and Agile, the focus is on quickly bringing product to market. We want the factory running at top speed to produce software. but we developers are human being, we need to think and feel, we need to create user stories, to deliver a product, but unfortunately the manufacturing metaphor looms ever strong in such thinking. The production aspects of Japanese auto manufacturing, of an assembly-line world, inspire much of Scrum.

Here we want to see how the auto industry handles this, the bulk of the work lies not in manufacturing but in maintenance. In software, 80% or more of what we do is quaintly called maintenance: The act of repair.

In about 1951, a quality approach called Total Productive Maintenance (TPM) came on the Japanese scene. Its focus is on maintenance rather than on production. One of the major pillars of TPM is the set of so-called 5S principles

• Seiri ,Knowing where things are — using approaches such as suitable naming — is crucial.
• Seiton , or tidiness (“systematize” ). “A place for everything, and everything in its place”. A piece of code should be where you expect to find it.
• Seiso , or cleaning (“shine”): Keep the workplace free of hanging wires, grease, scraps, and waste. littering your code with comments and commented-out code lines.
• Seiketsu, or standardization: The group agrees about how to keep the workplace clean.(Team work)
• Shutsuke, or discipline ( ‘self-discipline’). This means having the discipline to follow the practices and to frequently reflect on one’s work and be willing to change.(pull requests)

As we maintain automobiles and other machines under TPM, breakdown maintenance — waiting for bugs to surface — is the exception. Instead, we go up a level: inspect the machines every day and fix wearing parts before they break:

In code, refactor mercilessly.

we should probably re-do major software chunks from scratch every seven years or so to sweep away creeping cruft. Perhaps we should update this time constant to an order of weeks, days or hours instead of years. That’s where detail lies.

How can we make sure we wind up behind the right door when the going gets tough? The answer is: craftsmanship.

There are two parts to learning craftsmanship: knowledge and work. You must gain the knowledge of principles, patterns, practices, and heuristics that a craftsman knows, and you must also grind that knowledge into your fingers, eyes, and gut by working hard and practicing.

Chapter 1 : Clean Code

An example of bad code :

I know of one company that, in the late 80s, wrote a killer app. It was very popular, and lots of professionals bought and used it. But then the release cycles began to stretch. Bugs were not repaired from one release to the next. Load times grew and crashes increased. I remember the day I shut the product down in frustration and never used it again. The company went out of business a short time after that.

It was the bad code that brought the company down.

Have you ever been significantly impeded by bad code? If you are a programmer of any experience then you’ve felt this impediment many times. Indeed, we have a name for it. We call it wading.

What is clean code?

Bjarne Stroustrup, inventor of C++and author of The C++ Programming Language:

“I like my code to be elegant and efficient. ”

Grady Booch, author of Object Oriented Analysis and Design with Applications:

“Clean code is simple and readable. It reads like a well-written prose.”

“Big” Dave Thomas, founder of OTI, godfather of the Eclipse strategy:

“Clean code is simple and readable. It makes it easy for other people to enhance it. It is testable. It has minimal dependencies. It is literate.”

Michael Feathers, author of Working Effectively with Legacy Code:

“ Clean code always looks like it was written by someone who cares.”

Ron Jeffries, author of Extreme Programming Installed and Extreme Programming Adventures in C#:

“clean code: Runs all the tests; Contains no duplication; Expresses all the design ideas that are in the system;”

We Are Authors

The @author field of a Javadoc tells us who we are. We are authors. And one thing about authors is that they have readers. Indeed, authors are responsible for communicating well with their readers. The next time you write a line of code, remember you are an author, writing for readers who will judge your effort.

The Boy Scout Rule

The Boy Scouts of America have a simple rule that we can apply to our profession.

“Leave the campground cleaner than you found it.”

If we all checked-in our code a little cleaner than when we checked it out, the code simply could not rot.