- Paperback: 240 pages
- Publisher: Addison-Wesley Professional; 1 edition (November 4, 2004)
- Language: English
- ISBN-10: 9780321113580
- ISBN-13: 978-0321113580
- ASIN: 0321113586
- Product Dimensions: 7.3 x 0.6 x 9.1 inches
- Shipping Weight: 1.1 pounds (View shipping rates and policies)
- Average Customer Review: 4.5 out of 5 stars See all reviews (43 customer reviews)
- Amazon Best Sellers Rank: #295,090 in Books (See Top 100 in Books)
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
C++ Coding Standards: 101 Rules, Guidelines, and Best Practices 1st Edition
Use the Amazon App to scan ISBNs and compare prices.
Prepare for your professional certification with study guides and exam prep tools from Wiley. See more
Frequently bought together
Customers who bought this item also bought
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 Standards" will help you write cleaner code--and write it faster, with fewer hassles and less frustration.
About the Author
Herb Sutter is the author of three highly acclaimed books, Exceptional C++ Style, Exceptional C++, and More Exceptional C++ (Addison-Wesley). He chairs the ISO C++ standards committee, and is contributing editor and columnist for C/C++ Users Journal. As a software architect for Microsoft, Sutter leads the design of C++ language extensions for .NET programming.
Andrei Alexandrescu is the author of the award-winning book Modern C++ Design (Addison-Wesley, 2001) and is a columnist for C/C++ Users Journal.
Browse award-winning titles. See more
If you are a seller for this product, would you like to suggest updates through seller support?
Top Customer Reviews
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.