Quotes from Robert C. Martin

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

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

The rules of software are the same today as they were in 1946, when Alan Turing wrote the very first code that would execute in an electronic computer.

If you are not holding back some energy in reserve, if you don't have a new plan, if you aren't going to change your behavior, and if you are reasonably confident in your original estimate, then promising to try is fundamentally dishonest. You are lying. And you are probably doing it to save face and to avoid a confrontation.

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.

The promise to try is an admission that you've been holding back, that you have a reservoir of extra effort that you can apply.

This is the world of the software development team. It's a world in which dates are frozen and requirements are continuously changing. And somehow in that context, the development team must drive the project to a good outcome.

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.

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.

The architecture of a system is defined by a set of software components and the boundaries that separate them.

A craftsman is someone who works quickly, but without rushing, who provides reasonable estimates and meets commitments. A craftsman knows when to say no, but tries hard to say yes. A craftsman is a professional.

If only we could pull this off one more time. If only we could just say we were done with implementation. But we can't, because the thing about implementation is that is actually has to be done. Analysis and design are not binary deliverables. They do not have unambiguous completion criteria. There's no real way to know that you are done with them. So we might as well be done on time.

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.

So now we enter the Death March Phase of the project. Customers are angry. Stakeholders are angry. The pressure mounts. Overtime soars. People quit. It's hell.

The component structure cannot be designed from the top down. It is not one of the first things about the system that is designed, but rather evolves as the system grows and changes.

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

A stitch in time saves nine. The early bird catches the worm. Don't put off until tomorrow what you can do today.

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

The team is working along at a certain productivity. Then new staff is added. Productivity plummets for a few weeks as the new people suck the life out of the old people. Then, hopefully, the new people start to get smart enough to actually contribute.

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

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.

If we are diligent about building well-formed and robust systems, we should never let little, convenient idioms lead to modularity breakdown. The startup process of object construction and wiring is no exception.

But if you want to understand what Agile is really all about, there is no better way than to study XP. XP is the prototype, and the best representative, of the essential core of Agile.

To do Agile right, you had to work in pairs, write tests first, refactor, and commit to simple designs. You had to work in short cycles, producing executable output in each. You had to communicate with business on a regular and continuous basis.