Quotes from Robert C. Martin

The measure of design quality is simply the measure of the effort required to meet the needs of the customer. If that effort is low, and stays low throughout the lifetime of the system, the design is good. If that effort grows with each new release, the design is bad. It's as simple as that.

Our employment contract made it clear that anything we invented belonged to our company. My boss told me: "You sold it to us for one dollar, and we didn't pay you that dollar.

A simple violation of substitutability, can cause a system's architecture to be polluted with a significant amount of extra mechanisms.

You can't make a reusable framework until you first make a usable framework. Reusable frameworks require that you build them in concert with several reusing applications.

Truth can only be found in one place: the code.

Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. ...[Therefore,] making it easy to read makes it easier to write.

It is not enough for code to work.

Slaves are not allowed to say no. Laborers may be hesitant to say no. But professionals are expected to say no. Indeed, good managers crave someone who has the guts to say no. It's the only way you can really get anything done.

So if you want to go fast, if you want to get done quickly, if you want your code to be easy to write, make it easy to read.

A long descriptive name is better than a short enigmatic name. A long descriptive name is better than a long descriptive comment.

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

The only way to go fast, is to go well.

If you're good at the debugger it means you spent a lot of time debugging. I don't want you to be good at the debugger.

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

Every time you write a comment, you should grimace and feel the failure of your ability of expression.

Of course bad code can be cleaned up. But it's very expensive.

Remember that code is really the language in which we ultimately express the requirements. We may create languages that are closer to the requirements. We may create tools that help us parse and assemble those requirements into formal structures. But we will never eliminate necessary precision—so there will always be code.

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.

Redundant comments are just places to collect lies and misinformation.

It is not the language that makes programs appear simple. It is the programmer that make the language appear simple!

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.

What would happen if you allowed a bug to slip through a module, and it cost your company $10,000? The nonprofessional would shrug his shoulders, say "stuff happens," and start writing the next module. The professional would write the company a check for $10,000!

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.

Why do most developers fear to make continuous changes to their code? They are afraid they'll break it! Why are they afraid they'll break it? Because they don't have tests.