Previous Table of Contents Next


Chapter 9
Managing C and C++ Development

DECK: Properly managing C/C++ development requires discipline

For a programmer working on a single program, a project leader coordinating several people building a complex application, or an MIS director responsible for a large staff and many projects, the key to managing C and C++ development is simple — discipline. Without discipline, a programmer easily loses control of his or her code’s reliability and maintainability. At higher levels, a lack of discipline reduces productivity and increases maintenance costs. Although the need for discipline applies to programming in all languages, using C and C++ amplifies its importance.

As this book demonstrates, C has scores of traps that can ensnare an unwary programmer. Without invoking discipline to stay clear of C’s traps, sooner or later — usually sooner — a programmer will get caught. And because C provides great freedom in combining low-level operations, there often are dozens of techniques for implementing a particular application function. If, through discipline, a consistent standard isn’t applied across programs and projects, maintenance becomes difficult and dangerous because a programmer can’t depend on his or her understanding of standard techniques. The potential for slip-ups is high when each section of code has to be learned from scratch.

Using C++ does not lessen the need for discipline. C++ retains almost all of C’s low-level operations and adds several additional layers of language features. Although classes, inheritance, templates, and other C++ language features allow a programmer to work at a higher level of abstraction, these features can also increase the complexity of writing programs, if they’re not used in a well-thought-out and highly consistent manner.

Discipline Has Its Rewards

Discipline also is the key to achieving gains in productivity and quality from code reuse — the major motivation behind the creation of C++. No matter how powerful C++ facilities are for object-oriented programming, a slapdash approach to creating classes won’t result in substantial code reuse. Because it’s too expensive and risky to reuse poorly organized, poorly documented, or unreliable classes, programmers using C++ will continue to write mostly from scratch, unless a class library makes their jobs easier, rather than harder.

By now it may sound like the only way to work with C or C++ is to keep a cane switch handy to whip programmers into submission. That’s not the case. The “discipline” I’m speaking of is more akin to the discipline good athletes demonstrate in the preparation and execution of their sport. Like successful athletes, top-flight programmers, project leaders, and managers have learned that although discipline takes effort, it brings satisfaction as well. Discipline can free developers from the crush of problems caused by little, unavoidable mistakes and can make possible the use of more powerful software development techniques.

In programming, discipline applies to creating and following programming standards and a well-defined development process. Many standards and process steps should be formal, written ones, but a programmer also must be disciplined enough to follow unwritten principles of good programming practice. For example, no simple written standard can say, for all circumstances, when to reuse an existing class and when to create a new one. In the absence of any written standard, an undisciplined programmer might choose whichever is easiest at the moment; a disciplined programmer will examine the alternatives and carefully consider the balance between short- and long-term costs and benefits. In general, discipline involves thinking about more than just a single program, and thinking beyond just today’s problems.

How Big Is the World?

As a C programmer, project leader, or manager, you can’t control the whole world of C programming. So what’s a reasonable domain to concentrate on? Single programs, and even projects, are too narrow in scope. If a programmer has to learn new styles, techniques, and tools when he or she moves among programs or projects, the benefits of knowledge and code reuse are small. On the other hand, for most important C and C++ programming issues, there are no industry-wide standards. The various standards for lexical style (e.g., “K&R”) are only a minor aspect of C/C++ programming standards and, in many cases, are simply not very good.

The target to shoot for is company- or site-wide standards. Based on the size and geographical distribution of the programming staff, try to cover a domain that meets two criteria:

*  A person covered by the standards has a reasonable opportunity to participate in the development and revision of the standards.
*  A person who continues to work for the organization is likely to remain within the domain covered by the standards (i.e., in most cases, if they change assignments, they’ll still follow the same standards).

As you develop standards, keep in mind that nobody can include in written standards a rule to cover every situation a programmer will encounter. There’s no way to turn C or C++ programming into a mechanical task. Standards should record a sensible set of guidelines so programmers can use consistent styles and techniques — standards aren’t laws.

Here’s an example that involves indenting. On PCs, it’s convenient to set eight-character tab-stop intervals (i.e., 9, 17, 25, etc.) because the MS-DOS TYPE and PRINT commands, and many tools, use this default. Consequently, adopting the same interval for indenting in C programs is a reasonable standard. In some cases, however, a section of a program may have enough levels of nesting that statements begin very far to the right when displayed by an editor or when printed. As a result, statements may either need to be “chopped” up and continued across multiple lines, or they will be inconvenient to display or print.


Previous Table of Contents Next