Review: Clean Code Book of Robert C. Martin

You are a developer, do you want to be a better developer?

What is the difference between good code and bad code?

How to write good code and how to transform bad code into good code?

The objective of the article summarizes some of the main chapters in the book so that you save time and have look quickly about Clean Code.

Clean Code includes 17 chapters from low-level (chapter 2 - 6) to higher level concepts (chapter 7 - 13) and case studies (chapter 14 - 17).


Chapter 1. What is Clean Code

Have many definitions about Clean Code. 

Grady Booch said: "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."

Bjarne Stroustrup said: "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."


Chapter 2. Meaningful Name

How to create good names ???

- Should:

  • Use Intention-Revealing Names
  • Make Meaningful Distinctions
  • Pronounceable Names
  • Use Searchable Names 

- Should not:

  • Encodings
  • Be Cute
  • Pun (same word for two purposes)

Improve the readability of your code.

Chapter 3. Function

"Master programmers think of systems as stories to be told rather than programs to be written."

Follow the rules:

  • The first rule of function is Small!
  • Done one thing.
  • Function Arguments (should < 3).
  • DRY (Don’t Repeat Yourself).
  • Descriptive Name.

How Do You Write Functions Like This?

Writing software is like any other kind of writing. When you write a paper or an article, you get your thoughts down first, then you massage it until it reads well. The first draft might be clumsy and disorganized, so you wordsmith it and restructure it and refine it until it reads the way you want it to read. 
When I write functions, they come out long and complicated. They have lots of indenting and nested loops. They have long argument lists. The names are arbitrary, and there is duplicated code. But I also have a suite of unit tests that cover every one of those clumsy lines of code. 
So then I massage and refine that code, splitting out functions, changing names, eliminating duplication. I shrink the methods and reorder them. Sometimes I break out whole classes, all the while keeping the tests passing. 
In the end, I wind up with functions that follow the rules I’ve laid down in this chapter. I don’t write them that way to start. I don’t think anyone could.
If you follow the rules herein, your functions will be short, well named, and nicely organized. But never forget that your real goal is to tell the story of the system, and that the functions you write need to fit cleanly together into a clear and precise language to help you with that telling.


Chapter 4. Comment

"Don’t comment bad code—rewrite it."

- Comment do not make up for bad code.

- You will not use comment when you write a descriptive function or class.

Say NO with comment code =))

Chapter 5. Formatting 

The purpose of Formatting is let’s be clear. Code formatting is important. It is too important to ignore and it is too important to treat religiously.

Code formatting is about communication, and communication is the professional developer’s first order of business.

A good software system is composed of a set of documents that read nicely. They need to have a consistent and smooth style. The reader needs to be able to trust that the formatting gestures he or she has seen in one source file will mean the same thing in others. 

Chapter 6. Object and Data Structure

There is a reason that we keep our variables private. We don’t want anyone else to depend on them. We want to keep the freedom to change their type or implementation on a whim or an impulse. Why, then, do so many programmers automatically add getters and setters to their objects, exposing their private variables as if they were public?

- Law of Demeter: the Object Never Talks to Strangers.

- Objects hide their data behind abstractions and expose functions that operate on that data. Data structure expose their data and have no meaningful functions.


This is a great book for every developer who want to be a better developer.

Have you read Clean Code? Let me know what you think about this book in the comments.

I hope so this article is useful for you :)