Robert C. Martin (1) (1952–)

A good book to read for any coder - perhaps not as thorough as Code Complete but much more effective than Pragmatic Programmer.

This book's biggest strength is that it includes tons of code examples, including some fairly long and in depth ones. Instead of just listing rules or principles of clean code, many of the chapters go through these code examples and iteratively improve them. The rules and principles fall out of this process and the reader is a part of developing them, which is an show more effective way to learn.

I also liked the justification for why clean code matters in the intro chapters. However, there was not enough discussion of real world trade offs. The book brushes them aside and claims that the programmer should *always* write the most clean code possible; what is not mentioned is to what extent to do this and when. In fact, the book compares code to poetry and art and makes a point to mention that neither is ever done. And yet, everyone needs to ship at some point. So when is code not just clean, but clean enough?

Some downsides: the chapters have different authors, so a few are weaker than others. Also, the book is too tailored to Java and imperative/OO programming. Similar to Code Complete, this book would benefit from discussing functional programming, which addresses many of the lessons/problems.

Some fun quotes from Clean Code:


We want the factory running at top speed to produce software. These are human factories: thinking, feeling coders who are working from a product backlog or user story to create product.

Yet even in the auto industry, the bulk of the work lies not in manufacturing but in maintenance—or its avoidance. In software, 80% or more of what we do is quaintly called “maintenance”: the act of repair.

You should name a variable using the same care with which you name a first-born child.

Quality is the result of a million selfless acts of care—not just of any great method that descends from the heavens.

You are reading this book for two reasons. First, you are a programmer. Second, you want to be a better programmer. Good. We need better programmers.

Remember that code is really the language in which we ultimately express the requirements.

LeBlanc’s law: Later equals never.

Michael Feathers: 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 some- one who cares deeply about the craft.

Language bigots everywhere, beware! It is not the language that makes programs appear simple. It is the programmer that make the language appear simple!

The ratio of time spent reading vs. writing is well over 10:1.

Books on art don’t promise to make you an artist. All they can do is give you some of the tools, techniques, and thought processes that other artists have used. So too this book cannot promise to make you a good programmer. It cannot promise to give you “code-sense.” All it can do is show you the thought processes of good programmers and the tricks, tech- niques, and tools that they use.

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.

Every system is built from a domain-specific language designed by the programmers to describe that system. Functions are the verbs of that language, and classes are the nouns. This is not some throwback to the hideous old notion that the nouns and verbs in a requirements document are the first guess of the classes and functions of a system. Rather, this is a much older truth. The art of programming is, and has always been, the art of language design.

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

The proper use of comments is to compensate for our failure to express ourself in code. Note that I used the word failure. I meant it. Comments are always failures. We must have them because we cannot always figure out how to express ourselves without them, but their use is not a cause for celebration.

"Objects are abstractions of processing. Threads are abstractions of schedule.” —James O. Coplien

Concurrency is a decoupling strategy. It helps us decouple what gets done from when it gets done.

Boolean arguments loudly declare that the function does more than one thing.

Names in software are 90 percent of what make software readable. show less

Apparently I was looking for a book on Clean "Code" and ended up reading this by accident (architecture is synonymous with code right?!). Since I have read few coding books (despite nearly 40 years self-taught) I learned a bunch of things. Nevertheless, I should read his book on Code. Probably the biggest takeaway is that res-usability is the single biggest concept in software - nothing new, but nice to know it's easy to be a pro. Also, not to leave commented-out code laying around, get rid show more of most comments, and keep reducing function size is a never ending process. With the advent of AI, I can ask to redo functions in "clean code" style - might not follow the results exactly, but it teaches what clean code can look like vs. in theory from a book. show less

I have very mixed feelings about this book. Early on, it made me quite mad. But somewhere in the middle, it suddenly started to make sense. By the end, even though I still didn't agree with everything, I really appreciated the point that it's trying to make, and can agree with it.
Don't get me wrong, there are plenty of problems: so many of the examples are either bogus or have glaring problems of their own, there's a lot of bloat and back-patting in the prose, and to say this book is show more programming language agnostic is a massive lie. There are large sections devoted to the most Java-centric issues and examples, and it renders a lot of the advice from these sections meaningless for anyone using a different language.
My recommendation: start with the last chapter. If you feel like anything it says doesn't make sense or is unjustified, go back and read the related section. Reading the whole thing is a recipe for frustration. show less

I wanted to love this book, but instead I just sort of liked it. This book is a member of the extensive genre of books on how to write clean code. It sits alongside books like Code Complete by Steve McConnell[1] and many others. Where Clean Code promised to differentiate itself was in the use of three case studies -- about a third of the book -- showing Martin's code cleanup techniques in action.

However, I was disappointed by that section. As someone who codes and reviews code show more professionally, the case studies were not particularly enlightening. As seems obvious in retrospect, watching someone clean-up code in fairly straightforward ways is not interesting if you do and see that everyday. What I really wanted was a book on being a better code reviewer with advice on how to spot areas for improvement and convince others of the value of those improvements.

The examples could be useful for someone who isn't in a code-review-heavy environment. Martin does a reasonably good job of taking code that may seem reasonable on the surface and improving its readabilty. That said, his comments indicate that he often has a higher opinion of the cleanliness of his end result than I do.

As for the general advice and discussion of how to make clean code, I agree with a lot of his tips and disagree with others. Code cleanliness is an area where the core of just-plain-good ideas is surrounded by a nimbus of sometimes contradictory standards that people pick and choose from. The details of what you choose from the nimbus generally does not matter so much as consistency. (Of course, the real trouble occurs when people don't agree on what belongs in the core and what belongs in the nimbus.)

The book definitely was not a bad read, but it did not fit my needs.

[1] Still my favorite in the genre. show less