Quotes from Robert C. Martin

Say what you mean. Mean what you say.

These comments are so noisy that we learn to ignore them. As we read through code, our eyes simply skip over them. Eventually the comments begin to lie as the code around them changes.

if I must encode either the interface or the implementation, I choose the implementation. Calling it ShapeFactoryImp, or even the hideous CShapeFactory, is preferable to encoding the interface.

Indeed, many of the recommendations in this book are controversial. You will probably not agree with all of them.

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

A good manager drives a project to be good enough, fast enough, cheap enough, and done as much as necessary. A good manager manages the coefficients on these attributes rather than demanding that all those coefficients are 100%. It is this kind of management that Agile strives to enable.

1. "First make it work." You are out of business if it doesn't work. 2. "Then make it right." Refactor the code so that you and others can understand it and evolve it as needs change or are better understood. 3. "Then make it fast." Refactor the code for "needed" performance.

We programmers simply do not know how long things will take. This isn't because we are incompetent or lazy; it's because there is simply no way to know how complicated a task is going to be until that task is engaged and finished. But, as we'll see, all is not lost.

What this team did not realize was that having dirty tests is equivalent to, if not worse than, having no tests.

Clean code can be read, and enhanced by a developer other than its original author. It has unit and acceptance tests. It has meaningful names. It provides one way rather than many ways for doing one thing. It has minimal dependencies, which are explicitly defined, and provides a clear and minimal API. Code should be literate since depending on the language, not all necessary information can be expressed clearly in code alone. -Dave Thomas, founder of OTI, godfather of the Eclipse strategy

If you let the tests rot, then your code will rot too. Keep your tests clean.

Good software designs accommodate change without huge investments and rework. When we use code that is out of our control, special care must be taken to protect our investment and make sure future change is not too costly.

We want our code to be a quick skim, not an intense study.

abstraction is evil. Code is anti-evil, and clean code is perhaps divine.

It is unit tests that keep our code flexible, maintainable, and reusable. The reason is simple. If you have tests, you do not fear making changes to the code! Without tests every change is a possible bug.

The cost of automating acceptance tests is so small in comparison to the cost of executing manual test plans that it makes no economic sense to write scripts for humans to execute.

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

If you think good architecture is expensive, try bad architecture. —Brian Foote and Joseph Yoder

Complexity kills. It sucks the life out of developers, it makes products difficult to plan, build, and test." —Ray Ozzie, CTO, Microsoft Corporation

Factories are a complexity that can often be avoided, especially in the early phases of an evolving design.

Yet attentiveness to detail is an even more critical foundation of professionalism than is any grand vision. First, it is through practice in the small that professionals gain proficiency and trust for practice in the large. Second, the smallest bit of sloppy construction, of the door that does not close tightly or the slightly crooked tile on the floor, or even the messy desk, completely dispels the charm of the larger whole. That is what clean code is about.

Lots of very funny code is written because people don't take the time to understand the algorithm.

It is not enough for code to work. Code that works is often badly broken. Programmers who satisfy themselves with merely working code are behaving unprofessionally. They may fear that they don't have time to improve the structure and design of their code, but I disagree. Nothing has a more profound and long-term degrading effect upon a development project than bad code.

Database schemas are notoriously volatile, extremely concrete, and highly depended on. This is one reason why the interface between OO applications and databases is so difficult to manage, and why schema updates are generally painful.