- Amazon Student members save an additional 10% on Textbooks with promo code TEXTBOOK10. Enter code TEXTBOOK10 at checkout. Here's how (restrictions apply)
C++ Coding Standards: 101 Rules, Guidelines, and Best Practices Paperback – Oct 25 2004
|New from||Used from|
Special Offers and Product Promotions
Frequently Bought Together
Customers Who Bought This Item Also Bought
No Kindle device required. Download one of the Free Kindle apps to start reading Kindle books on your smartphone, tablet, and computer.
To get the free app, enter your e-mail address or mobile phone number.
From the Inside Flap
Get into a rut early: Do the same process the same way. Accumulate idioms. Standardize. The only difference(!) between Shakespeare and you was the size of his idiom list-not the size of his vocabulary.
--Alan Perlis emphasis ours
The best thing about standards is that there are so many to choose from.
We want to provide this book as a basis for your team's coding standards for two principal reasons:
A coding standard should reflect the community's best tried-and-true experience: It should contain proven idioms based on experience and solid understanding of the language. In particular, a coding standard should be based firmly on the extensive and rich software development literature, bringing together rules, guidelines, and best practices that would otherwise be left scattered throughout many sources.
Nature abhors a vacuum: If you don't consciously set out reasonable rules, usually someone else will try to push their own set of pet rules instead. A coding standard made that way usually has all of the least desirable properties of a coding standard; for example, many such standards try to enforce a minimalistic C style use of C++.
Many bad coding standards have been set by people who don't understand the language well, don't understand software development well, or try to legislate too much. A bad coding standard quickly loses credibility and at best even its valid guidelines are liable to be ignored by disenchanted programmers who dislike or disagree with its poorer guidelines. That's "at best"--at worst, a bad standard might actually be enforced.How to Use This Book
Think. Do follow good guidelines conscientiously; but don't follow them blindly. In this book's Items, note the Exceptions clarifying the less common situations where the guidance may not apply. No set of guidelines, however good (and we think these ones are), should try to be a substitute for thinking.
Each development team is responsible for setting its own standards, and for setting them responsibly. That includes your team. If you are a team lead, involve your team members in setting the team's standards; people are more likely to follow standards they view as their own than they are to follow a bunch of rules they feel are being thrust upon them.
This book is designed to be used as a basis for, and to be included by reference in, your team's coding standards. It is not intended to be the Last Word in coding standards, because your team will have additional guidelines appropriate to your particular group or task, and you should feel free to add those to these Items. But we hope that this book will save you some of the work of (re)developing your own, by documenting and referencing widely-accepted and authoritative practices that apply nearly universally (with Exceptions as noted), and so help increase the quality and consistency of the coding standards you use.
Have your team read these guidelines with their rationales (i.e., the whole book, and selected Items' References to other books and papers as needed), and decide if there are any that your team simply can't live with (e.g., because of some situation unique to your project). Then commit to the rest. Once adopted, the team's coding standards should not be violated except after consulting with the whole team.
Finally, periodically review your guidelines as a team to include practical experience and feedback from real use.Coding Standards and You
Good coding standards can offer many interrelated advantages:
- Improved code quality: Encouraging developers to do the right things in a consistent way directly works to improve software quality and maintainability.
- Improved development speed: Developers don't need to always make decisions starting from first principles.
- Better teamwork: They help reduce needless debates on inconsequential issues and make it easier for teammates to read and maintain each other's code.
- Uniformity in the right dimension: This frees developers to be creative in directions that matter.
Under stress and time pressure, people do what they've been trained to do. They fall back on habit. That's why ER units in hospitals employ experienced, trained personnel; even knowledgeable beginners would panic.
As software developers, we routinely face enormous pressure to deliver tomorrow's software yesterday. Under schedule pressure, we do what we are trained to do and are used to doing. Sloppy programmers who in normal times don't know good practices of software engineering (or aren't used to applying them) will write even sloppier and buggier code when pressure is on. Conversely, programmers who form good habits and practice them regularly will keep themselves organized and deliver quality code, fast.
The coding standards introduced by this book are a collection of guidelines for writing high-quality C++ code. They are the distilled conclusions of a rich collective experience of the C++ community. Much of this body of knowledge has only been available in bits and pieces spread throughout books, or as word-of-mouth wisdom. This book's intent is to collect that knowledge into a collection of rules that is terse, justified, and easy to understand and follow.
Of course, one can write bad code even with the best coding standards. The same is true of any language, process, or methodology. A good set of coding standards fosters good habits and discipline that transcend mere rules. That foundation, once acquired, opens the door to higher levels. There's no shortcut; you have to develop vocabulary and grammar before writing poetry. We just hope to make that easier.
We address this book to C++ programmers of all levels:
If you are an apprentice programmer, we hope you will find the rules and their rationale helpful in understanding what styles and idioms C++ supports most naturally. We provide a concise rationale and discussion for each rule and guideline to encourage you to rely on understanding, not just rote memorization.
For the intermediate or advanced programmer, we have worked hard to provide a detailed list of precise references for each rule. This way, you can do further research into the rule's roots in C++'s type system, grammar, and object model. At any rate, it is very likely that you work in a team on a complex project. Here is where coding standards really pay off-you can use them to bring the team to a common level and provide a basis for code reviews.About This Book
We have set out the following design goals for this book:
Short is better than long: Huge coding standards tend to be ignored; short ones get read and used. Long Items tend to be skimmed; short ones get read and used.
Each Item must be noncontroversial: This book exists to document widely agreed upon standards, not to invent them. If a guideline is not appropriate in all cases, it will be presented that way (e.g., "Consider X..." instead of "Do X...") and we will note commonly accepted exceptions.
Each Item must be authoritative: The guidelines in this book are backed up by references to existing published works. This book is intended to also provide an index into the C++ literature.
Each Item must need saying: We chose not to define new guidelines for things that you'll do anyway, that are already enforced or detected by the compiler, or that are already covered under other Items.
Example: "Don't return a pointer/reference to an automatic variable" is a good guideline, but we chose not to include it in this book because all of the compilers we tried already emit a warning for this, and so the issue is already covered under the broader Item 1, "Compile cleanly at high warning levels."
Example: "Use an editor (or compiler, or debugger)" is a good guideline, but of course you'll use those tools anyway without being told; instead, we spend two of our first four Items on "Use an automated build system" and "Use a version control system."
Example: "Don't abuse goto" is a great Item, but in our experience programmers universally know this, and it doesn't need saying any more.
Each Item is laid out as follows:
- Item title: The simplest meaningful sound bite we could come up with as a mnemonic for the rule.
- Summary: The most essential points, briefly stated.
- Discussion: An extended explanation of the guideline. This often includes brief rationale, but remember that the bulk of the rationale is intentionally left in the References.
- Examples (if applicable): Examples that demonstrate a rule or make it memorable.
- Exceptions (if applicable): Any (and usually rare) cases when a rule doesn't apply. But beware the trap of being too quick to think: "Oh, I'm special; this doesn't apply in my situation"-that rationalization is common, and commonly wrong.
- References: See these parts of the C++ literature for the full details and analysis.
In each section, we chose to nominate a "most valuable Item." Often, it's the first Item in a section, because we tried to put important Items up front in each part; but other times an important Item couldn't be put up front, for flow or readability reasons, and we felt the need to call it out for special attention in this way.
From the Back Cover
Consistent, high-quality coding standards improve software quality, reduce time-to-market, promote teamwork, eliminate time wasted on inconsequential matters, and simplify maintenance. Now, two of the world's most respected C++ experts distill the rich collective experience of the global C++ community into a set of coding standards that every developer and development team can understand and use as a basis for their own coding standards.
The authors cover virtually every facet of C++ programming: design and coding style, functions, operators, class design, inheritance, construction/destruction, copying, assignment, namespaces, modules, templates, genericity, exceptions, STL containers and algorithms, and more. Each standard is described concisely, with practical examples. From type definition to error handling, this book presents C++ best practices, including some that have only recently been identified and standardized-techniques you may not know even if you've used C++ for years. Along the way, you'll find answers to questions like
- What's worth standardizing--and what isn't?
- What are the best ways to code for scalability?
- What are the elements of a rational error handling policy?
- How (and why) do you avoid unnecessary initialization, cyclic, and definitional dependencies?
- When (and how) should you use static and dynamic polymorphism together?
- How do you practice "safe" overriding?
- When should you provide a no-fail swap?
- Why and how should you prevent exceptions from propagating across module boundaries?
- Why shouldn't you write namespace declarations or directives in a header file?
- Why should you use STL vector and string instead of arrays?
- How do you choose the right STL search or sort algorithm?
- What rules should you follow to ensure type-safe code?
Whether you're working alone or with others,C++ Coding Standardswill help you write cleaner code--and write it faster, with fewer hassles and less frustration.
See all Product Description
Inside This Book(Learn More)
What Other Items Do Customers Buy After Viewing This Item?
Top Customer Reviews
Many people may have found that coding alone can be a slow process which lets you overlook mistakes that a team would normaly notice. Such mistakes could lead to very major security holes, or just a disliked product from you and/or your company. The thought is more than one programmer, a team of programmers must certainly be faster and more effecient.
This is however not always the case since in a team. If there is inadequate communication, a few people may try and code the same thing at once or it may not be clear who's supposed to update the code into one large updated project with each member's new code additions. Or what if some of the members didnt comment their code? C++ Coding Standards is the perfect book for co-ordinating an aimless mass of coders into a clean, profficient, powerful, programming machine.
This book will take some of the most simple to the more advanced strategies of making your team a "Team" by using many different strategies. Throughout the book you are not required to attempt any of the suggestions in the book, as they were careful to word things in such a manner as "Consider X..." instead of "Do X...". The suggestions and guidelines that you find in C++ Coding standards have been used in many published works, which you are given examples of in the book. If you are looking to organize, motivate, and kickstart your team onto the path of success and haste, I suggest this book as a very good starting point.
Most Helpful Customer Reviews on Amazon.com (beta)
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.
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.
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.
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 [...]
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.
Look for similar items by category
- Books > Computers & Technology > Microsoft > Development > C & C++ Windows Programming
- Books > Computers & Technology > Programming > C
- Books > Computers & Technology > Programming > Languages & Tools
- Books > Computers & Technology > Software
- Books > Qualifying Textbooks - Fall 2007 > Computers & Internet
- Books > Textbooks > Computer Science & Information Systems > Programming Languages