Customer Reviews

C++ Coding Standards: 101 Rules, Guidelines, and Best Practices

5 star:		(17)
4 star:		(8)
3 star:		(5)
2 star:		(1)
1 star:		(0)

 

 

For many programmers, the term "coding standard" generates a gut-level response. We all know that someone is going to be pushing the "one, true brace style" or the "proper" way to indent code. This subject is probably the best way to generate instantaneous rebellion among a group of programmers.

The first "standard" in "C++ Coding Standards" wipes all of that away with their first rule:

0. Don't sweat the small stuff. (Or: know what not to standardize.)

In one quick entry, Sutter and Alexandrescu sweep all of the indent-level, brace-placement, CamelCase/underscores holy wars into a single category and give a useful bit of advice: <em>Be consistent.</em> The authors point out that any professional programmer should be able to read and write in any of these styles. The differences are basically a matter of personal preference.

From this point on, we get to see a coding standard that is focused on "best practices" and proven techniques for improving code.

This is the only coding standard I've ever seen that would really help a group of programmers improve their work.

I love both this book and Effective C++ for different reasons. The Effective C++ series is mainly very low level hints that help you avoid the pitfalls that C++ has in store for you. This book, while showing a lot of code, gives a higher level perspective of the areas it covers (e.g. templates, STL, class design, namespaces, etc.). That perspective grounds you in an understanding of the topic, then binds that to some real world code examples. Both approaches are very valuable. I would recommend getting both books. You can't live without the practical advice of Effective C++ or the architectural material in C++ Coding Standards.

Sutter and Alexandrescu are certified C++ gurus, and have each written classic works on C++ (Exceptional C++ series, and Modern C++ Design, respectively). So why does this book fall short? Because it doesn't go into the level of detail necessary to make every recommendation meaningful, and instead relies on citations of previous works. And those citations very often fall into a handful of books that every serious C++ programmer should own and understand anyway: Effective C++ series by Scott Meyers, The C++ Programming Language by Bjarne Strousup, and Exceptional C++ by Sutter.

One might argue that 5 books or more is too many, and that this book adds value by providing a one stop ultimate resource for best practices. The problem is that if proper justification isn't provided for each best practice, it's difficult for readers to internalize them. Even if these guys are experts, and a, "trust me" will suffice to believe what they say, it doesn't mean that everyone will understand what they say without diving into the other books that they so often reference. And that brings us back to my main point: you may as well just buy and read the original books in the first place.

Many of the items are complete repeats of items from Scott Meyers books with much less explanation. For example, number 81 of best practices, 'Prefer range operations to single-element operations', is the same as item 5 in 'Effective STL'. However, in Coding Standards, a page is devoted to the explanation; not sufficient if you don't already fully understand why this is a good practice. Meyers, on the other hand, spends 8 pages fully convincing you it is a good idea with several examples. After reading Meyers, I'm going to understand and remember the practice of preferring range member functions.

If you already own all of Scott Meyer's books, along with some of Sutter's and want a concise summary of coding practices, this book may be worth while. Otherwise, start with the original works.

I have great respect for both authors from reading their other books/articles, and there are many good ideas in this book, but I was expecting to agree with the authors here much more than I do.

Item 0: Don't sweat the small stuff. The authors say not to overlegislate naming and bracing standards, but they also say "do be consistent" and don't mix styles. From personal experience, I can say the only way to get a group of programmers to be consistent is by "sweating the small stuff" and having well-defined policies that are strictly enforced.

Item 1: Zero tolerance of warnings. Eliminating Level 4 warnings (in Visual C++) from a complex application (as opposed to a library intended for third-party use) is more trouble than it's worth. The authors' suggestion to decrease code readability (Examples 2 and 3) to get around these warnings is quite a bad idea, in my opinion.

Item 59: I wish somehow there could be a better answer to the C++ namespace issue. Giving many symbols (but not all, like preprocessor macros, classes not in a namespace, etc.) two names (the qualified and the unqualified) based on where that symbol appears seems so wrong and at the very least makes searching and cut-and-pasting more difficult.

The authors clearly prefer use of stl over custom containers (although they have not always followed their own advice), but they don't address many issues related to this, like are teams using stl supposed to use the peculiar stl naming practices across the board in all code, so stl dictates naming and all projects would use naming like some_stl_vector.push_back()? Or would code like m_object.DoSomething() be mixed together with the above statement so there really is no standard? What are programmers to do when the stl containers don't cut it and a custom container is needed? Should they write it in the stl idiom or consistent with their own naming standard?

Many of the examples refer to std::string, and even a few use const char *, in a book like this I would prefer not to see uses of these types that are not localization-friendly, since it is a best practices type of book, after all.

The book's proofreaders are very good but I believe they missed one error on Item 61, page 112, near the bottom: "Do not definite..." I'm assuming should be "Do not define..."

Anyway, I do recommend this book, and I do agree with most of the items, the authors raise many good points to consider when a team is deciding on its own coding standard.

Herb Sutter and Andrei Alexandrescu have been long time contributors to the C++ community, so every time I see their names on a book, I expect to be challenged in how I think about developing software - I always have high expectations.

When I originally saw this book's title, I was thinking that the subject would be primarily about coding conventions. This is an area of interest to me, as I have 20+ years experience in software development and have set up our company's C++ coding conventions.

However, once I saw the table of contents, I realized that this would have a bit more depth than a coding convention. I think that this book is mis-titled; it ought to be "101 C++ Guidelines and Best Practices".

There is a distinction between coding conventions and "guidelines and best practices." Coding conventions that I have seen tend to delve into code micromanagement, usually for business rather than technical reasons (i.e., being able to more easily swap developers around).

The authors address this indirectly with the first item: "0. Don't sweat the small stuff. (Or: know what not to standardize)" (Note the bit of C++ humor in starting the numbering at 0!) In this item, the authors dispatch the notion of "stylistic issues" and focus for the remainder of the book on practical technical advice.

The areas that these guidelines cover include: Organizational and Policy Issues; Design Style; Coding Style; Functions and Operators; Design and Inheritance; Construction, Destruction, and Copying; Namespaces and Modules; Templates and Genericity; Error Handling and Exceptions; STL: Containers; STL: Algorithms; and Type Safety. I would strongly urge you to obtain a detailed breakout of the table of contents to help evaluate the appropriateness of this book to you (see http://www.gotw.ca/publications/c++cs.htm).

The authors assert that this book is for the whole spectrum of developers, beginners through advanced. For the most part, I agree with them. The biggest challenge with this subject matter is that those developers who have not been "burned" in the past will not always appreciate the wisdom espoused in these items. Take heed when they say that a lesson has been learned through "bitter experience."

Although there are 101 items in this book, I think there are one or two that are weak. One in particular, "99. Don't use invalid objects. Don't use unsafe functions," seems to address issues that should be obvious to even beginners.

On the other end of the spectrum, there are a couple of items whose efficacy is debatable. Consider item 39, "Consider making virtual functions non-public, and public functions non-virtual." I have seen the arguments for this design technique argued many times in the comp.lang.c++ group. I understand all the arguments in its favor, but personally have not yet put this into practice.

In the middle of these extremes are 97 or 98 very useful pieces of advice. As technical books tend to be expensive, most of us need to be choosey. This is one book that will pay back its cost many times over.

It's Sutter! It's Alexandrescu! It's both of them together! And the dark lords of C++ have combined forces to produce... er, some coding standards.

Yes, another book of best practices. Some readers may therefore be a tad disappointed that the combined fruits of the authors' labours will not be shattering their puny human minds with the sort of C++ that cause lesser compilers to accidentally create black holes that destroy the entire universe.

But let's evaluate the book on what it sets out to do, which is to give 100 bite-sized pieces of advice on C++ coding. And it's very good. You might prefer to see it as an annotated guide to the state of the art in intermediate C++ programming, in particular to Sutter's Exceptional C++ trilogy, which has become sufficiently sprawling that a reorganisation of the material, plus pointers to which book said what, has become quite welcome.

Yes, it's true that C++ is hardly short of books telling you when to pass by value. But take a look at the bibliography - it's a synthesis of all those other tomes (the Effective series, Sutter's own Exceptional series of course, and older books like C++ Strategy and Tactics) plus magazine articles, into a neat and compact whole.

Few of the items are longer than one or two pages. This is good because the advice stays simple, clear and direct. On the other hand, some of the items feel a bit squeezed into the available space, with discussion deferred to the books in the references, which is a little frustrating on occasion. After all, a lot of the best parts of the Exceptional C++ and Effective C++ series and their ilk is not so much what to do (or not to do), but the why behind it. There's plenty of the former, but not so much of the latter.

If you've read any other coding convention books (like those in Steve McConnell's Code Complete) then the first quarter of the book may feel like the same old same old. And of course with there being exactly 100 items, some are more heavyweight than others. But there's definite C++ meat here, in particular with the items on Exceptions and the STL.

C++ Coding Standards is as well-written as you'd expect from the authors - their friendly, slightly conversational writing styles mesh nicely and I couldn't tell who wrote which bits. And it's a great summary and unification of C++ best practices that someone just starting out could easily refer to in their initial forays. Perhaps even more experienced hands will discover a few tips, implications or issues that they hadn't considered before. It could also be a good way to ensure that a team are all up to date on best practices.

Essential for those with a large C++ library? Probably not, but it does the job it sets out to do very well.

The subtitle about "101 rules..." evokes comparison with O'Reilly's series of "100 Hacks on...". But coincidential or not, the authors do provide many useful rules if you are a serious C++ programmer who is looking to make your code more robust and easier to debug.

However, there is some padding done by the authors, to reach this fabled 101 total. They added some elementary rules that are often well-described in many C++ or C texts. Like rule 17 - "Avoid magic numbers". In other words, define constants to hold these values. Or rule 18, about declaring variables as locally as possible. You do know these already, I hope.

Later in the book, they actually get to more worthwhile discussions. Like rule 52, about copying and destroying consistently. Or rule 72, about using exceptions instead of error codes to report errors.

Overall, most of the book can be useful to you. Though I think the authors would have done well to junk some trite rules.

Herb and Andrei have done an outstanding job of collecting, condensing and organizing many man years of hard won pearls of wisdom into a concise collection of brief notes. This is a very readable book with a broad range of applicability to all C++ programmers. It is organized such that after the first read, it makes an excellent reference, complete with a dozen page "Summary of Summaries" which should not be overlooked at the end of the book.

One of the features I like best about this book is that not only does each item have a rationale, but most items also have a section describing when the item should be disregarded. This book is not a substitute for thinking. Rather it is a tool to help the reader think more clearly. Therefore it has earned a prominent place on my bookshelf (I can use all the help I can get).

This is a must read for intermediate level and higher programmers. One of the book's strengths is its conciseness, which makes it easier to read without getting tied up in a lot of details. Because of this, the reader must take it upon himself/herself to check the readings in the supplied references (given for each rule) to completely understand the terms/idioms/ideas mentioned in the rule. This is not at all a weakness in the book, as it's purpose is to summarize the rule/guideline/practice, so they can put it to use, while leaving it up to the reader to refer to readings in the given references, to obtain a greater understanding of the ideas used in that rule. Most of the references can be found in the authors' previous works. The book also makes reference to standard time tested design patterns and ideas, so it would be good to have the text "Design Patterns" read, or close by.

You have never seen a book quite like this before. When the authors of this book speak, the C++ community listens, but together they have outdone themselves, and you and I are the happy beneficiaries. This is the first "coding standards" book I've seen that works. The organization is clear and intuitive, the topics are pertinent, and the content is of the highest quality. All the standards contained herein have been rigorously scrutinized (I have hundreds of emails to prove it!) by a generous sampling of the leading contributors in the C++ world, as attested by the acknowledgements in the Preface.

More than just style guidelines and "gotcha" warnings, C++ Coding Standards clarifies the idioms and practices that pertain specifically to successful C++ software. Even better, you can't avoid deepening your mastery of the finer points of C++ as you read. This is the singularly authoritative Writ of Common Wisdom for the entire C++ development experience.

Chuck Allison
Editor, The C++ Source