 |
|
The material in the book is about evenly divided between C and C++. Each section dispenses general design and programming philosophy, followed by more specific programming information (about specific language features). The advice about general programming and design is the best thing in a very good book; the rules are relevant to any programming language, are sensible, and have enduring value: "If you can't say it in English, you can't say it in C/C++." "A problem must be thought through before it can be solved."
Many of the tips in this book fall into the areas of "programming style" and "subtle interactions." Holub suspects that many programmers are out there writing buggy C++ code: Either they're using language features they don't really understand or they don't take the time to do a real object-oriented design. This puts them in danger of writing "unmaintainable gobbledygook." He doesn't believe in using C++ as a better C. If you're going to use C++, use it whole hog and do good object-oriented design. "If it's not object- oriented, use C," he says.
This book doesn't just cover language features with subtle behavior, however. Sections on constructors and destructors, references, virtual functions, templates and exceptions show these constructs in use, in addition to illuminating the darker corners of semantics. There's also much ordinary advice in the book: how to avoid multiple inclusion of header files, guidance on commenting and naming your identifiers. Many of the tips merely document the behavior of good programmers everywhere (I hope).
Holub is also not subtle about sharing opinions, or about being controversial: In a C++ class, all data members should be private, "No exceptions," he says. He doesn't believe in setter and getter functions, for example. Messages in object-oriented systems should implement features or services; they shouldn't be used to set or get a data member. Of course, much commercial C++ code contains the very faults he describes. One of these commercial systems is MFC, and the author gives many convincing examples of its faults. Holub is not trying to bury MFC, but he's not trying to praise it either.
This book was published in 1995, when the C++ standard wasn't yet completed. If it were updated, not a heck of a lot would change, I suspect. Perhaps namespaces might be recommended highly to avoid polluting the global space, or a few warnings about nonstandard compilers would be toned down.
I find myself consulting this book after a language text, to get its unique point of view. Like any book on etiquette, you may agree and disagree with some of the rules. You may even feel argumentative at times. But I found the book stimulates thought about programming -- and a few arguments around the shop.
-- Doug Nickerson (doug_nickerson@onsetcomp.com)
| Readability |
|
| Originality |
|
| Organization |
|
| Accuracy |
|
| Consistency |
|
| Depth |
|
| Timeliness |
|
| Editing |
|
| Design |
|
| Overall Value |
|
Explanation of ERCB rating scale: No stars = unacceptable, 1 Star = marginal, 2 Stars = average, 3 Stars = above average, 4 Stars = exceptional.