Alexandre Lim

I recommend Clean Code for every programmer. It was my first book about Software Development. A new journey as a software developer began after reading it. I was surprised by how easy it was to read, even for a technical book. It made me a better professional.

Notes

In software, 80% or more of what we do is “maintenance”—the act of repair.

Quality is the result of a million selfless acts of care.

The code is the design.

There are two parts to learning craftsmanship: knowledge and work.

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.

Programs that are that clean are so profoundly well written that you don’t even notice it. It is not the language that makes programs appear simple. It is the programmer that make the language appear simple.

Making the code easy to read actually makes it easier to write.

It’s not enough to write the code well. The code has to be kept clean over time.

The length of a name should correspond to the size of its scope.

Professionals use their power and write code that others can understand.

The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that. Functions should do one thing. They should do it well. They should do it only.

We want the code to read like a top-down narrative.

More than three arguments in a function requires very special justification—and they shouldn’t be used anyway.

Functions should either do something or answer something, but not both.

Duplication may be the root of all evil in software. Don’t Repeat Yourself.

The proper use of comments is to compensate for our failure to express ourself in code.

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

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

Law of Demeter: a module should not know about the innards of the objects it manipulates.

Error handling is important, but if it obscures the logic, it’s wrong.

It’s better to depend on something you control than on something you don’t control, lest it end up controlling you. We manage third-party boundaries by having very few places in the code that refer to them.

Test code is just as important as production code. Clean tests are about readability.

Loosening encapsulation is always a last resort.

Classes should have one responsibility—one reason to change (Single Responsibility Principle). Maintaining a separation of concerns is just as important in our programming activities as it is in our programs.

When cohesion is high, it means that the methods and variables of the class are co-dependent and hang together as a logical whole.

Classes should depend upon abstractions, not on concrete details (Dependency Inversion Principle).

It is a myth that we can get systems “right the first time”. Software systems are unique compared to physical systems. Their architectures can grow incrementally, if we maintain the proper separation of concerns.

To write clean code, you must first write dirty code and then clean it.

Nothing has a more profound and long-term degrading effect upon a development project than bad code. Bad code rots and ferments, becoming an inexorable weight that drags the team down.

First make it work. Then, make it right.

Clean code is not written by following a set of rules. You don’t become a software craftsman by learning a list of heuristics. Professionalism and craftsmanship come from values that drive disciplines.