C++ Coding Standards: 101 Rules, Guidelines, and Best Practices (Anglais) Broché – 25 octobre 2004
|Neuf à partir de||Occasion à partir de|
- Choisissez parmi 17 000 points de collecte en France
- Les membres du programme Amazon Premium bénéficient de livraison gratuites illimitées
- Trouvez votre point de collecte et ajoutez-le à votre carnet d’adresses
- Sélectionnez cette adresse lors de votre commande
Produits fréquemment achetés ensemble
Les clients ayant acheté cet article ont également acheté
Descriptions du produit
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.
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.
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 numéro de téléphone mobile.
Détails sur le produit
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.
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.