Preface | p. xi |
Organizational and Policy Issues | p. 1 |
Don't sweat the small stuff. (Or: Know what not to standardize.) | p. 2 |
Compile cleanly at high warning levels | p. 4 |
Use an automated build system | p. 7 |
Use a version control system | p. 8 |
Invest in code reviews | p. 9 |
Design Style | p. 11 |
Give one entity one cohesive responsibility | p. 12 |
Correctness, simplicity, and clarity come first | p. 13 |
Know when and how to code for scalability | p. 14 |
Don't optimize prematurely | p. 16 |
Don't pessimize prematurely | p. 18 |
Minimize global and shared data | p. 19 |
Hide information | p. 20 |
Know when and how to code for concurrency | p. 21 |
Ensure resources are owned by objects. Use explicit RAII and smart pointers | p. 24 |
Coding Style | p. 27 |
Prefer compile- and link-time errors to run-time errors | p. 28 |
Use const proactively | p. 30 |
Avoid macros | p. 32 |
Avoid magic numbers | p. 34 |
Declare variables as locally as possible | p. 35 |
Always initialize variables | p. 36 |
Avoid long functions. Avoid deep nesting | p. 38 |
Avoid initialization dependencies across compilation units | p. 39 |
Minimize definitional dependencies. Avoid cyclic dependencies | p. 40 |
Make header files self-sufficient | p. 42 |
Always write internal #include guards. Never write external #include guards | p. 43 |
Functions and Operators | p. 45 |
Take parameters appropriately by value, (smart) pointer, or reference | p. 46 |
Preserve natural semantics for overloaded operators | p. 47 |
Prefer the canonical forms of arithmetic and assignment operators | p. 48 |
Prefer the canonical form of ++ and --. Prefer calling the prefix forms | p. 50 |
Consider overloading to avoid implicit type conversions | p. 51 |
Avoid overloading &&, [double vertical line], or, (comma) | p. 52 |
Don't write code that depends on the order of evaluation of function arguments | p. 54 |
Class Design and Inheritance | p. 55 |
Be clear what kind of class you're writing | p. 56 |
Prefer minimal classes to monolithic classes | p. 57 |
Prefer composition to inheritance | p. 58 |
Avoid inheriting from classes that were not designed to be base classes | p. 60 |
Prefer providing abstract interfaces | p. 62 |
Public inheritance is substitutability. Inherit, not to reuse, but to be reused | p. 64 |
Practice safe overriding | p. 66 |
Consider making virtual functions nonpublic, and public functions nonvirtual | p. 68 |
Avoid providing implicit conversions | p. 70 |
Make data members private, except in behaviorless aggregates (C-style structs) | p. 72 |
Don't give away your internals | p. 74 |
Pimpl judiciously | p. 76 |
Prefer writing nonmember nonfriend functions | p. 79 |
Always provide new and delete together | p. 80 |
If you provide any class-specific new, provide all of the standard forms (plain, in-place, and nothrow) | p. 82 |
Construction, Destruction, and Copying | p. 85 |
Define and initialize member variables in the same order | p. 86 |
Prefer initialization to assignment in constructors | p. 87 |
Avoid calling virtual functions in constructors and destructors | p. 88 |
Make base class destructors public and virtual, or protected and nonvirtual | p. 90 |
Destructors, deallocation, and swap never fail | p. 92 |
Copy and destroy consistently | p. 94 |
Explicitly enable or disable copying | p. 95 |
Avoid slicing. Consider Clone instead of copying in base classes | p. 96 |
Prefer the canonical form of assignment | p. 99 |
Whenever it makes sense, provide a no-fail swap (and provide it correctly) | p. 100 |
Namespaces and Modules | p. 103 |
Keep a type and its nonmember function interface in the same namespace | p. 104 |
Keep types and functions in separate namespaces unless they're specifically intended to work together | p. 106 |
Don't write namespace usings in a header file or before an #include | p. 108 |
Avoid allocating and deallocating memory in different modules | p. 111 |
Don't define entities with linkage in a header file | p. 112 |
Don't allow exceptions to propagate across module boundaries | p. 114 |
Use sufficiently portable types in a module's interface | p. 116 |
Templates and Genericity | p. 119 |
Blend static and dynamic polymorphism judiciously | p. 120 |
Customize intentionally and explicitly | p. 122 |
Don't specialize function templates | p. 126 |
Don't write unintentionally nongeneric code | p. 128 |
Error Handling and Exceptions | p. 129 |
Assert liberally to document internal assumptions and invariants | p. 130 |
Establish a rational error handling policy, and follow it strictly | p. 132 |
Distinguish between errors and non-errors | p. 134 |
Design and write error-safe code | p. 137 |
Prefer to use exceptions to report errors | p. 140 |
Throw by value, catch by reference | p. 144 |
Report, handle, and translate errors appropriately | p. 145 |
Avoid exception specifications | p. 146 |
STL: Containers | p. 149 |
Use vector by default. Otherwise, choose an appropriate container | p. 150 |
Use vector and string instead of arrays | p. 152 |
Use vector (and string::c_str) to exchange data with non-C++ APIs | p. 153 |
Store only values and smart pointers in containers | p. 154 |
Prefer push_back to other ways of expanding a sequence | p. 155 |
Prefer range operations to single-element operations | p. 156 |
Use the accepted idioms to really shrink capacity and really erase elements | p. 157 |
STL: Algorithms | p. 159 |
Use a checked STL implementation | p. 160 |
Prefer algorithm calls to handwritten loops | p. 162 |
Use the right STL search algorithm | p. 165 |
Use the right STL sort algorithm | p. 166 |
Make predicates pure functions | p. 168 |
Prefer function objects over functions as algorithm and comparer arguments | p. 170 |
Write function objects correctly | p. 172 |
Type Safety | p. 173 |
Avoid type switching; prefer polymorphism | p. 174 |
Rely on types, not on representations | p. 176 |
Avoid using reinterpret_cast | p. 177 |
Avoid using static_cast on pointers | p. 178 |
Avoid casting away const | p. 179 |
Don't use C-style casts | p. 180 |
Don't memcpy or memcmp non-PODs | p. 182 |
Don't use unions to reinterpret representation | p. 183 |
Don't use varargs (ellipsis) | p. 184 |
Don't use invalid objects. Don't use unsafe functions | p. 185 |
Don't treat arrays polymorphically | p. 186 |
Bibliography | p. 187 |
Summary of Summaries | p. 195 |
Index | p. 209 |
Table of Contents provided by Rittenhouse. All Rights Reserved. |