Search in Book Reviews

Herb Sutter gave me a manuscript copy of this book when I was in Redmond recently. I thought readers might like the benefit of a fast review from me before someone else does a more in depth review for a later issue of C Vu. (Note that at the time of writing the book is only on distribution in North America but by the time you read this it should be available in Europe - check elsewhere in this issue of C Vu because I hope to arrange some form of special Christmas deal including this book with Blackwells.)

Before I go any further, I should make it clear that this is a book about best practices for programming in C++. I find that some people do not clearly distinguish between 'language standards' (nothing to do with this book) and 'programming guidelines' (essentially what this book presents the basis for).

The book starts with some general (largely non-code specific) guidelines. The first of these can be summarised as exhorting the reader to not waste time on such minor issues as code layout, just be consistent (with the style used by the file you are maintaining, the rest of your code or with the team you are a member of). I suspect that there are readers who will get very heated about example 4 in guideline 0. This concerns SESE (single entry, single exit). Now I happen to agree with the authors that requiring SESE in a coding standard is archaic and no longer appropriate, however there are well-respected members of the C++ community who would very strongly disagree. The solution is to accept the basic spirit of the guideline and not get over-heated if your instructor insists your code should be SESE.

The reason that I took time to call out the above example is that it is a particular example of a general objective of the authors; this is not a book telling the reader what they must do, it is a book setting out some general principles. If you understand the intent of the book as a whole and the individual guidelines in particular you will be able to adopt and adapt to your own needs and environment.

Despite there being two authors, both highly competent, who have done their research with care and attention to detail there is, inevitably, a degree of subjectivity in their 101 'rules'.

The individual guidelines vary from very simple, very specific ones such as 'Avoid magic numbers' (#17) to rather more general ones such as 'Design and write error-safe code' (#71).

I think that #17 does not go far enough in either explaining when a numerical constant is a magic number. There is a difference between an arbitrary limit (such as the maximum size for an array) and a mathematical constant such as p. Both deserve to be named but for rather different reasons. On the other hand there are simple integer values (such as the number of feet in a yard) that do not deserve to be named if you are only using them in a context where the meaning is clear (length_in_feet = 3 * length_in_yards).

I also believe that this guideline would have been more powerful had it been 'Avoid magic' and then gone on to explain that using named (inline) functions avoids overly complicated 'magic' expressions and that a typedef can giving more meaning to the type you are reusing.

Almost every one of the 101 items provides a basis for discussion. That is as it should be. I would offer a meta-guideline 'Do not slavishly follow guidelines'. I will leave it to another place and time to expand on that.

Many of the items in this book are already known to experienced programmers but they deserve their place because this book should be one that is read and digested by everyone from the aspiring novice to the long-term expert.

Now, I wonder if the authors have started on 'More C++ Coding Standards'. If they haven't, they should because there is still much more wisdom that deserves encapsulation.