Robert C. Martin Quotes

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.

The way you keep software soft is to leave as many options open as possible, for as long as possible. What are the options that we need to leave open? They are the details that don't matter.

Any organisation that designs a system will produce a design whose structure is a copy of the organisation's communication structure

In an ideal system, we incorporate new features by extending the system, not by making modifications to existing code.

Redundant comments are just places to collect lies and misinformation.

On the other hand, a system being developed by five different teams, each of which includes seven developers, cannot make progress unless the system is divided into well-defined components with reliably stable interfaces. If no other factors are considered, the architecture of that system will likely evolve into five components - one for each team.

You see, programmers tend to be arrogant, self-absorbed introverts. We didn't get into this business because we like people. Most of us got into programming because we prefer to deeply focus on sterile minutia, juggle lots of concepts simultaneously, and in general prove to ourselves that we have brains the size of a planet, all while not having to interact with the messy complexities of other people.

If the discipline of requirements specification has taught us anything, it is that well-specified requirements are as formal as code and can act as executable tests of that code!

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.

Few practices are as odious as commenting-out code. Don't do this!

Code, without tests, is not clean. No matter how elegant it is, no matter how readable and accessible, if it hath not tests, it be unclean. Dave

Encapsulation is broken because all functions in the path of a throw must know about details of that low-level exception. Given that the purpose of exceptions is to allow you to handle errors at a distance, it is a shame that checked exceptions break encapsulation in this way.

Who can justify the expense of a six-lane highway through the middle of a small town that anticipates growth? Who would want such a road through their town?

The only way to prove that your software is easy to change is to make easy changes to it. And when you find that the changes aren't as easy as you thought, you refine the design so that the next change is easier. When do you make these easy changes? All the time! Every time you look at a module you make small, lightweight changes to it to improve its structure.

A good architecture will allow a system to be born as a monolith, deployed in a single file, but then to grow into a set of independently deployable units, and then all the way to independent services and/or micro-services.

Try to write tests that force exceptions, and then add behavior to your handler to satisfy your tests. This will cause you to build the transaction scope of the try block first and will help you maintain the transaction nature of that scope.

QA and Development should be working together to ensure the quality of the system. The

LeBlanc's law: Later equals never.

Whatever else a TODO might be, it is not an excuse to leave bad code in the system.

Programming is a social activity.

Good software systems begin with clean code. On the one hand, if the bricks aren't well made, the architecture of the building doesn't matter much. On the other hand, you can make a substantial mess with well-made bricks. This is where the SOLID principles come in.

The fact that we did not have a database running for 18 months of development meant that, for 18 months, we did not have schema issues, query issues, database server issues, password issues, connection time issues, and all the other nasty issues that raise their ugly heads when you fire up a database. It also meant that all our tests ran fast, because there was no database to slow them down.

The fact that the task to write perfect software is virtually impossible does not mean you aren't responsible for the imperfection.

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

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.

Building a project should be a single trivial operation.

If you can develop the high-level policy without committing to the details that surround it, you can delay and defer decisions about those details for a long time. And the longer you wait to make those decisions, the more information you have with which to make them properly.

Software has two types of value: the value of its behavior and the value of its structure. The second of these is the greater of the two because it is this value that makes software soft.

Indeed, most of us realize that the requirements are the most volatile elements in the project.

Duplication is the primary enemy of a well-designed system.

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

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.

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.
- Grady Booch author of Object
Oriented Analysis and Design with
Applications

The primary cost of maintenance is in spelunking and risk. Spelunking is the cost of digging through the existing software, trying to determine the best place and the best strategy to add a new feature or to repair a defect.

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

(refactored) /**

If your function must change the state of something, have it change the state of its owning object.

The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.

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.

Programmers must avoid leaving false clues that obscure the meaning of code.

What if the decisions have already been made by someone else? What if your company has made a commitment to a certain database, or a certain web server, or a certain framework? A good architect pretends that the decision has not been made, and shapes the system such that those decisions can still be deferred or changed for as long as possible.

A good architect maximizes the number of decisions not made.

Honesty in small things is not a small thing.

One of the best ways to ruin a program is to make massive changes to its structure in the name of improvement. Some programs never recover from such "improvements." The problem is that it's very hard to get the program working the same way it worked before the "improvement.

You should choose a set of simple rules that govern the format of your code, and then you should consistently apply those rules. If you are working on a team, then the team should agree to a single set of formatting rules and all members should comply.

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

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.

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

Duplication and expressiveness take me a very long way into what I consider clean code, and improving dirty code with just these two things in mind can make a huge difference. There is, however, one other thing that I'm aware of doing, which is a bit harder to explain.

Say what you mean. Mean what you say.

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.

Nothing has a more profound and long-term degrading effect upon a development project than bad code. Bad schedules can be redone, bad requirements can be redefined. Bad team dynamics can be repaired. But bad code rots and ferments, becoming an inexorable weight that drags the team down.

Adding manpower to a late project makes it later.

That these acts are simple doesn't mean that they are simplistic, and it hardly means that they are easy.

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.

-Bjarne Stroustrup, inventor of C++
and author of The C++ Programming
Language

The majority of the cost of a software project is in long-term maintenance.

This is the philosophy of YAGNI: "You aren't going to need it." There is wisdom in this message, since over-engineering is often much worse than under-engineering. On the other hand, when you discover that you truly do need an architectural boundary where none exists, the costs and risks can be very high to add such a boundary.

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

it's confusing to have a controller and a manager and a driver in the same
code base. What is the essential difference between a DeviceManager and a Protocol-Controller? Why are both not controllers or both not managers? Are they both Drivers really? The name leads you to expect two objects that have very different type as well as
having different classes.

A consistent lexicon is a great boon to the programmers who must use your code.

As strange as it may seem, this decision is one of the options that a good architect leaves open. A system that is written as a monolith, and that depends on that monolithic structure, cannot easily be upgraded to multiple processes, multiple threads, or micro-services should the need arise. By comparison, an architecture that maintains the proper isolation of its components, and does not assume the means of communication between those components, will be much easier to transition through the spectrum of threads, processes, and services as the operational needs of the system change over time.

We've seen several of these oscillations just in the last decade or so since the web became prominent. At first we thought all the computer power would be in server farms, and the browsers would be stupid. Then we started putting applets in the browsers. But we didn't like that, so we moved dynamic content back to the servers. But then we didn't like that, so we invented Web 2.0 and moved lots of processing back into the browser with Ajax and JavaScript. We went so far as to create whole huge applications written to execute in the browsers. And now we're all excited about pulling that JavaScript back into the server with Node.

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.

When you are working on a problem, you sometimes get so close to it that you can't see all the options. You miss elegant solutions because the creative part of your mind is suppressed by the intensity of your focus. Sometimes the best way to solve a problem is to go home, eat dinner, watch TV, go to bed, and then wake up the next morning and take a shower.

Abstraction is the elimination of the irrelevant and the amplification of the essential.

The hardest thing about choosing good names is that it requires good descriptive skills and a shared cultural background. This is a teaching issue rather than a technical, business, or
management issue.

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.

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.

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

God is in the details, said the architect Ludwig mies van der Rohe.

The LSP makes clear that in OOD the ISA relationship pertains to behavior. Not intrinsic private behavior, but extrinsic public behavior; behavior that clients depend upon.

The complement is also true: Procedural code makes it hard to add new data structures because all the functions must change. OO code makes it hard to add new functions because all the classes must change.

Perhaps you thought that "getting it working" was the first order of business for a professional developer. I hope by now, however, that this book has disabused you of that idea. The functionality that you create today has a good chance of changing in the next release, but the readability of your code will have a profound effect on all the changes that will ever be made.

Professionals use their powers for good and write code that others can understand.

The perfect kind of architecture decision is the one which never has to be made

If its dependencies are inverted, it has an OO design. If its dependencies are not inverted, it has a procedural design.

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

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.

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.