Code Maintenance Quotes

Don't document bad code - rewrite it.

Good code is its own best documentation. As you're about to add a comment, ask yourself, "How can I improve the code so that this comment isn't needed?" Improve the code and then document it to make it even clearer.

Don't hurry your code. Make sure it works well and is well designed. Don't worry about timing.

Hosting various versions of my countdown program has kept me extremely busy, and I loved every minute of it.

When you write a program, think of it primarily as a work of literature. You're trying to write something that human beings are going to read. Don't think of it primarily as something a computer is going to follow. The more effective you are at making your program readable, the more effective it's going to be: You'll understand it today, you'll understand it next week, and your successors who are going to maintain and modify it will understand it.

Even if you aren't in doubt, consider the mental welfare of the person who has to maintain the code after you, and who will probably put parens in the wrong place.

We have a rule that if you check in code, you have to maintain it. So I mostly code on the side. I don't check in code anymore.

It is easier to tear down a code than to put a new one in its place.

The cost of adding a feature isn't just the time it takes to code it. The cost also includes the addition of an obstacle to future expansion. The trick is to pick the features that don't fight each other.

All programming is maintenance programming, because you are rarely writing original code.

The Escalation programmers come from a completely different background, and the codebase is all STL this, boost that, fill-up-the-property list, dispatch the event, and delegate that. I had been harboring some suspicions that our big codebases might benefit from the application of some more of the various “modern” C++ design patterns, despite seeing other large game codebases suffer under them. I have since recanted that suspicion.

If there is a bug in your code than you have to drop everything you're doing and go fix it.

Most of the effort in the software business goes into the maintenance of code that already exists.

Software as an asset isn't stable over time; it needs to be maintained.

The mark of a mature programmer is willingness to throw out code you spent time on when you realize it's pointless.

Renaming a class at one level is really easy; you just change the name. But how do you change all the references to that class and all the imports?