Techniques

I had the second part of this book all figured out: I would introduce advanced features of C++ one by one, with examples. I would do templates and exceptions and write a chapter about my favorite resource management. Then I would show the perils of concurrent programming and how to avoid them, the clever tricks with virtual memory and I’d finish up with a series of Windows programs.

Then I started preparing a course for students and suddenly realized that it wouldn’t work. Well, it would in some way, but not the way I wanted it. I didn’t want to come up with a random bag of tricks, like so many "experience" books do. (Nor did I want to produce a new theory of program development.) What I really wanted is to show how programming works in real-life situations. In real life you don’t come up with a new trick and start looking around for the opportunity to use it. A much more likely scenario is that you are faced with a problem that has to be solved and you need to know what your options are. Or you are trying to spot potential problems in your or somebody else’s code and prevent them.

The problem is that, in order to demonstrate the usefulness of advanced techniques, one needs to work with examples of more substantial programs. Of course, I could keep inventing stories like: "Imagine you wrote a large system that was supposed to distribute luggage in a big airport. The system was just allocating an entry for a suitcase when it ran out of memory. A null suitcase was created and caused a plane to GP-fault."

And then I realized that there is no better opportunity for a programmer to learn about programming than by taking part in code reviews. This is how my coworkers and I honed our skills, both when defending our own code and when critiquing others’ code.

The rules of engagement were very simple: The reviewer was always right. If the reviewer couldn’t understand somebody’s code, the code had to be redesigned. If the reviewer thought that the names of variables were too cryptic, they had to be changed. Of course, arguing was allowed; but if the reviewed was not able to convince the reviewer, the reviewed was the loser.

Instead of writing yet another program for the course and code reviewing it, I looked at what I already had--the calculator from the first part of the book. The code looked okay, it was object oriented, nicely structured, seemingly bug free. Yet I couldn’t say it was a solid piece of programming that I would like to sign with my name. It worked, but:

The fact that the program works has no relevance.

Any fool can write a program that runs. I decided to give the calculator a thorough code review. I imagined that it was written by a novice programmer (someone who had just learned C++ by reading the first part of this book). My role was to help the person turn this piece of amateur code into an industrial strength program.

What follows is a series of code reviews that result in quite substantial changes in the program. Besides demonstrating various advanced programming techniques they prove one more important point: Substantial changes are possible and beneficial. The saying "If it ain’t broke, don’t fix it." should be banned from serious discussion about software development. Instead another saying should be adopted:

If you can’t write programs that can be modified, don’t bother.

In fact, it is often for the best to toss out the unmaintainable code and start all over from scratch (although it might be impossible to convince the management about it). Fortunately, we don’t have to toss out the calculator. As you’ll see it is highly maintainable. Not bad for an amateurish program.

To get the most out of this part of the book, you should try working with the project's source code. Try making all the changes described in code reviews and, after each chapter, compare your code with the one I provided. Being able to modify a program is probably the most important skill of any programmer.