C++ Coding Standards: 101 Rules, Guidelines, and Best Practices (Anglais) Broché – 25 octobre 2004
|Neuf à partir de||Occasion à partir de|
Produits fréquemment achetés ensemble
Les clients ayant acheté cet article ont également acheté
Descriptions du produit
Quatrième de couverture
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.
Biographie de l'auteur
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.
Aucun appareil Kindle n'est requis. Téléchargez l'une des applis Kindle gratuites et commencez à lire les livres Kindle sur votre smartphone, tablette ou ordinateur.
Pour obtenir l'appli gratuite, saisissez votre adresse e-mail ou numéro de téléphone mobile.
Détails sur le produit
En savoir plus sur les auteursDécouvrez des livres, informez-vous sur les écrivains, lisez des blogs d'auteurs et bien plus encore.
Dans ce livre(En savoir plus)
Quels sont les autres articles que les clients achètent après avoir regardé cet article?
Commentaires en ligne
Commentaires client les plus utiles sur 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.