C++ supports programming-in-the-large, allowing relationships between different parts of a program to be expressed. The scope of C++ programming style therefore goes beyond traditional in-the-small issues which relate to the details of line-by-line coding. This book examines the use of the in-the-large language features of C++, which sometimes confuse even experienced programmers. The author demonstrates that unwarranted use of the more powerful language features may lead to cluttered programs which are harder to comprehend and sometimes less efficient than more straightforward alternatives. Cargill rewrites several programs, using techniques that range from improving consistency to removing redundant inheritance. The presentation simulates a code review, in which readers may independently evaluate and criticize alternative approaches to programming problems, and then compare their analyses with those of the author.
Design and coding style rules are distilled from the examples. Understanding and following these rules will help professional programmers design and write better C++ programs.
A chapter is devoted to each of the following topics:
Style Example: Pricing Computers.
Finding a Common Abstraction.
Differences Between Classes.
Removing the Enumerations.
Style Example: Class string.
Consistent Physical State.
Consistent Use of Dynamic Memory.
Deallocating Dynamic Memory.
Style Example: A Second Approach.
Style Example: Stacks.
Inheritance Scope Rules.
Interface versus Implementation.
Style Example: Vehicles and Garages.
Operator Overloading Basics.
Style Example: Class FileArray.
Inheritance for Implementation.
A Programming Tradeoff: Overloaded Operators versus Member Functions.
A C Library.
Style Example: A C++ Wrapper for dirent.
Multiple Directory Objects.
Public Access to Failure State.
Error Condition Argument.
Style Example: Class BigInt.
The Length of Dynamic Strings.
The Number of Dynamic Strings.
The Client Code.
Style Example: Finite State Machines.
Modules versus Abstract Data Types.
Ambiguities under Multiple Inheritance.
Directed Acyclic Inheritance Graphs.
Exploring Virtual Base Classes.
Style Example: Class Monitor.
Style Example: A Virtual Base Class.
Multiple Protocol Inheritance.
Almost two decades after the publication of Kernighan and Plauger's classic, The Elements of Programming Style, its compact set of rules remains the best general guidance on good programming. Today, however, our programs are larger and our programming languages have changed. We now care as much about how the components of a program fit together as we do about the algorithms and data structures used in each component. DeRemer and Kron coined the terms programming-in-the-large and programming-in-the-small to make a distinction between the large-scale and small-scale aspects of programs. By programming-in-the-small, they meant dealing with components of a program that are "one to a few pages long" - the size of a typical C++ class. By programming-in-the-large, they meant the structuring of in-the-small components into a program - in C++ terms, dealing with relationships between classes. Kernighan and Plauger concentrated their work on the issues of programming-in-the-small. Their advice about programming-in-the-large is sound, but minimal.
I have adopted Kernighan and Plauger's method of distilling rules of programming style from the critical reading and rewriting of programs. All the programs used here are taken from textbooks, magazine articles and tutorials on C++ programming. None was created artificially for this work. Some programs are presented exactly as originally published, while others have been altered cosmetically. The alterations range from the correction of in-the-small bugs, which would only distract, to structure-preserving transformations of programs for which copyright was not obtained.
The spirit in which to approach the material is that of an "egoless" code review. We all learn by reading and reviewing each other's programs. The material is not a criticism of individual programmers - it seeks only to differentiate between good and bad programs. No doubt the programs that are presented here as "better" versions have their own shortcomings. The reader is encouraged to examine these programs critically, looking for further improvements in programming style.