Code Complete

by Steve McConnell

When the Empire State Building was built, each delivery truck had a 15-minute margin in which to make its delivery. If a truck wasn't in place at the right time, the whole project was delayed.

Some programmers do know how to perform upstream activities, but they don't prepare because they can't resist the urge to begin coding as soon as possible. If you feed your horse at this trough, I have two suggestions. Suggestion 1: Read the argument in the next section. It may tell you a few things you haven't thought of. Suggestion 2: Pay attention to the problems you experience. It takes only a few large programs to learn that you can avoid a lot of stress by planning ahead.

The first prerequisite you need to fulfill before beginning construction is a clear statement of the problem that the system is supposed to solve. This is sometimes called "product vision," "vision statement," "mission statement," or "product definition." Here it's called "problem definition."

Programmers who program "into" a language first decide what thoughts they want to express, and then they determine how to express those thoughts using the tools provided by their specific language.

Establish programming conventions before you begin programming. It's nearly impossible to change code to match them later.

Horst Rittel and Melvin Webber defined a "wicked" problem as one that could be clearly defined only by solving it, or by solving part of it (1973). This paradox implies, essentially, that you have to "solve" the problem once in order to clearly define it and then solve it again to create a solution that works.

There are two ways of constructing a software design: one way is to make it so simple that there are obviously no deficiencies, and the other is to make it so complicated that there are no obvious deficiencies.

The bottom line is that programmers who compensate for inherent human limitations write code that's easier for themselves and others to understand and that has fewer errors.

When I am working on a problem I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong.

Programming is not like being in the CIA; you don't get credit for being sneaky. It's more like advertising; you get lots of credit for making your connections as blatant as possible.

You and your co-worker sit together in a conference room and draw design alternatives on a whiteboard.

Be critical of classes that contain more than about seven data members. The number "7±2" has been found to be a number of discrete items a person can remember while performing other tasks (Miller 1956).

You might be tempted to create a class derived from Cat named ScratchlessCat and override the Scratch() routine to do nothing. This approach presents several problems: It

If multiple classes share common data but not behavior, create a common object that those classes can contain. If multiple classes share common behavior but not data, derive them from a common base class that defines the common routines. If multiple classes share common data and behavior, inherit from a common base class that defines the common data and routines. Inherit when you want the base class to control your interface; contain when you want to control your interface.

It's good practice to initialize the return value at the beginning of the function to a default value—this provides a safety net in the event that the correct return value is not set.

In debug mode, Microsoft Word contains code in the idle loop that checks the integrity of the Document object every few seconds. This helps to detect data corruption quickly, and it makes for easier error diagnosis.

Example 8-14. C++ Example of Using the Preprocessor Macro to Control Debug Code #define DEBUG #if defined( DEBUG ) #define DebugCode( code_fragment ) { code_fragment } #else #define DebugCode( code_fragment ) #endif ...