C++ Coding Standards : 101 Rules, Guidelines, and Best Practices (C++ in Depth Series)

Rating:
Summary: Good material regardless of your language preferences...
Review: Although I'm not a C++ programmer, I was still able to get value from the book C++ Coding Standards - 101 Rules, Guidelines, and Best Practices by Herb Sutter and Andrei Alexandrescu (Addison Wesley).

Chapter List: Preface; 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; Type Safety; Bibliography; Summary of Summaries; Index

This book consists of 101 tips and guidelines that each run between 1 to 3 pages in length. There's a short summary statement of the tip (like "Sharing causes contention: Avoid shared data, especially global data."), followed by a discussion of the tip along with exceptions to the rule and further references if you want to read more about the subject. There's a range of tips for all experience levels, so developers at all levels should be able to gain at least one or two tips that will help them on a daily basis.

I'm not a C++ developer, but there is plenty of common sense material here for all developers (such as Java programmers). The first three chapters will largely apply to just about any developer, and should be taken to heart regardless of platform. So while you may not run right out and buy it if you're not a C++ developer, definitely read it if you get the opportunity.

Rating:
Summary: Wow, this is a great book!
Review: C++ Coding Standards : 101 Rules, Guidelines, and Best Practices is awesome. If you code in c++, you will wonder how you ever get along without the great advice in the book.

Rating:
Summary: Finally, a coding standard that programmers can accept.
Review: 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.

Rating:
Summary: Excellent book
Review: 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).

Rating:
Summary: Guidelines for real developers
Review: 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.



Rating:
Summary: Many good ideas
Review: 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.




Rating:
Summary: Higher level than Effective C++
Review: 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.

Rating:
Summary: Some padding
Review: 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.

Rating:
Summary: It rocks! Get it for every C++ developer you work with
Review: This book rocks!

When my copy first arrived, I stayed up way too late reading it cover to cover, which is something I rarely do with technical, nonfiction books. It is that good.

I brought it into work the day after, and every person who stopped by my office glanced at it and agreed with me. I have since ordered a copy for every C++ developer in my division, got buy-in from other divisions, and am replacing our current company coding standard with it as the foundation.

Following the advise in this book will make one a better C++ programmer. Just get it, read it, and you'll be better at your craft.

Rating:
Summary: Packed with time tested great advice
Review: 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.