At STA-5 in 1988 I gave a paper with the deliberately provocative title The Case for Large Languages . My main opposition at that time came from the community of C enthusiasts, who kept pointing out how small C was. A bright programmer could learn the whole C language quickly, and efficient implementations would fit on the smallest computer configurations.

Since then, however, we've heard very little about how small C is, and there's a good reason. With the object-oriented extensions in C++ and the absolutely essential library modules you need in order to do anything in today's GUI environments, C/C++ has now become the largest programming langauge ever, far outsrtipping PL/I and Ada.

Like other large languages C/C++ presents a multiplicity of ways to do just about anything. Any organization that hopes to exploit the power and reusability of OOP in C++ had better adopt a set of strong standards, conventions, and guidlines for choosing among the dozens of available techniques and style variations.

Since Ranade and Nash address the pure C language while Myers focuses on object-oriented facilities in C++, there's almost no overlap or conflict between them. The serious C++ programmer should keep both on the nearest bookshelf. Organizations or project teams establishing internal programming standards or quality-assurance programs, should find the the combination a wealth of useful ideas.

Note that I said useful not perfect or complete. Ranade and Nash may go farther than many of us are comfortable with in extolling low-level "C idioms" that aren't as clear as other techniques. Myers's folksy style cloys on repeated reading. Neither covers certain vital topics in business applications programming. Nevertheless, I can enthusiastically endorse 90 percent of their content as necessary (but by no means sufficient) foundation for good practice in C/C++.

Addendum -- December, 1999

Although I still endorse the great bulk of Ranade and Nash's recommendations, two of them are dated, and are now considered poor practice:

1. "13.2 Use Parameters as local variables"
   This practice conflicts with the use of const, and will not only confuse the reader but also generate compiler errors.
2. "11.3 Use a instead of a!=0 . . . "
   The addition of a boolean type to the language, as well as consistency with Java coding, make this traditional C practice, which still works, harder to defend.

Return to book reviews.

Return to table of contents.