Cover -- Half-title -- Title -- Copyright -- Contents -- Preface -- Audience -- 1 Introduction -- Disclaimer -- Acknowledgments -- 2 General Principles -- 1. Adhere to the Style of the Original -- 2. Adhere to the Principle of Least Astonishment -- 3. Do It Right the First Time -- 4. Document any Deviations -- 3. Formatting Conventions -- 3.1 Indentation -- 5. Use Indented Block Statements -- 6. Indent Statements after a Label -- 7. Choose One Style for Brace Placement -- 8. Break Long Statements into Multiple Lines -- 9. Include White Space -- 10. Do Not Use "Hard" Tabs -- 4. Naming Conventions -- 4.1 Preprocessor Macro Names -- 11. Use UPPERCASE and Underscores for Preprocessor Macro Names -- 12. Add a Unique Prefix to Macro Names -- 4.2 Type and Constant Names -- 13. Use "UpperCamelCase" for Classes, Constants, Structures, Enumerations, and Typedefs -- 14. Use Nouns to Name Compound Types -- 15. Pluralize the Names of Collections -- 4.3 Function Names -- 16. Use "lowerCamelCase" for Function Names -- 17. Use Verbs to Name Functions -- 18. Use "is", "set", and "get" to Name Accessor and Mutator Functions -- 4.4 Variable and Parameter Names -- 19. Use "lowerCamelCase" for Variable and Function Parameter Names -- 20. Use Nouns to Name Variables -- 21. Add a Prefix or Suffix to Member Variable Names to Distinguish Them from Other Variables -- 22. Name All Function Parameters -- 23. Use "other" for Parameter Names in Copy Constructors and Assignment Operators -- 24. Give Function Parameters the Same Name as the Member Variables You Assigned Them to -- 4.5 General -- 25. Use Meaningful Names -- 26. Use Familiar Names -- 27. Avoid the Use of Digits within Names -- 28. Avoid Excessively Long Names -- 29. Join the Vowel Generation-Use Complete Words -- 30. Use "lowerCamelCase" for Abbreviations -- 31. Do Not Use Case to Differentiate Names.

5. Documentation Conventions -- 32. Document Your Software Interface for Those Who Must Use It -- 33. Document Your Implementation for Those Who Must Maintain It -- 34. Keep Your Comments and Code Synchronized -- 35. Embed Application Program Interface (API) Reference Documentation in Your Source Code -- 36. Generate API Reference Documentation Directly from the Source Code -- 37. Document All Significant Software Elements -- 38. Document Software Elements as Early as Possible -- 39. Use Block Comments to Describe the Programming Interface -- 40. Use One-Line Comments to Explain Implementation Details -- 41. Use a Single Consistent Format and Organization for All Documentation Comments -- 42. Provide a Summary Description of Every Declared Element -- 43. Document the Interface Exposed by Every Function -- 44. Document Thread Synchronization Requirements -- 45. Provide Examples to Illustrate Common and Proper Usage -- 46. Document Important Preconditions, Postconditions, and Invariant Conditions -- 47. Document Known Defects and Deficiencies -- 48. Use the Active Voice to Describe Actors and Passive Voice to Describe Actions -- 49. Use "this" Rather Than "the" When Referring to Instances of the Current Class -- 50. Explain Why the Code Does What It Does -- 51. Avoid the Use of End-Line Comments -- 52. Label Closing Braces in Highly Nested Control Structures -- 53. Add a "fall-through" Comment between Two case Labels if no break Statement Separates Those Labels -- 54. Use Keywords to Mark Pending Work, Unresolved Issues, Defects, and Bug Fixes -- 6. Programming Principles -- 6.1 Engineering -- 55. Do Not be Afraid to Do Engineering -- 56. Choose Simplicity over Elegance -- 57. Do Not Use a Feature of C++ just "because it is there" -- 58. Recognize the Cost of Reuse -- 59. Program by Contract -- 6.2 Class Design -- 60. Keep Classes Simple.

61. Define Subclasses So They May be Used Anywhere Their Superclasses May be Used -- The Liskov Substitution Principle -- The Open-Closed Principle -- 62. Use Inheritance for "is a" Relationships and Containment for "has a" Relationships -- 63. Avoid Multiple Inheritance -- 6.3 Thread Safety and Concurrency -- 64. Design for Reentrancy -- 65. Use Threads only Where Appropriate -- 66. Avoid Unnecessary Synchronization -- 67. Do Not Synchronize Access to Code That Does Not Change Shared State -- 7. Programming Conventions -- 7.1 Preprocessor -- 68. Use '#include"..."' for Collocated Header Files and '#include' for External Header Files -- 69. Place Preprocessor Include Guards in Header Files -- 70. Use…Comments to Hide Blocks of Code -- 71. Use Macros Sparingly -- 72. Add a Semicolon after Every Statement Expression Macro -- 73. Use Macros to Capture the Current File Name and Line Number -- 74. Do Not Use "#define" to Define Constants---Declare static const Variables Instead -- 7.2 Declarations -- 75. Use Portable Types for Portable Code -- 76. Use Typedefs to Simplify Complicated Type Expressions -- 77. Create a Zero-Valued Enumerator to Indicate an Uninitialized, Invalid, Unspecified, or Default State -- 78. Do Not Define Enumerations Using Macros or Integer Constants -- 7.3 Scoping -- 79. Declare Enumerations within a Namespace or Class -- 80. Declare Global Functions, Variables, or Constants as Static Members of a Class -- 81. Declare for-loop Iteration Variables Inside of for Statements -- 7.4 Functions and Methods -- 82. Use an Enumeration Instead of a Boolean to Improve Readability -- 83. Use an Object Pointer Instead of a Reference if a Function Stores a Reference or Pointer to the Object -- 84. Accept Objects by Reference and Primitive or Pointer Types by Value -- 85. Use a const char* for Narrow Character String Parameters.

86. Pass Enumerator Values, Not Integer Constants -- 87. Do Not Use void* in a Public Interface -- 88. Use Inline Functions Instead of Macros -- 89. Inline Only the Simplest of Functions -- 90. Factor Functions to Allow Inlining of Trivial Cases -- 7.5 Classes -- 91. Define Small Classes and Small Methods -- 92. Build Fundamental Classes from Standard Types -- 93. Avoid the Use of Virtual Base Classes in User-Extensible Class Hierarchies -- 94. Declare the Access Level of All Members -- 95. Declare All Member Variables Private -- 96. Avoid the Use of Friend Declarations -- 7.6 Class Members -- 97. Declare an Explicit Default Constructor for Added Clarity -- 98. Always Declare a Copy Constructor, Assignment Operator, and Destructor if the Class can be Instantiated -- 99. Always Implement a Virtual Destructor If Your Class May be Subclassed -- 100. Make Constructors Protected to Prohibit Direct Instantiation -- 101. Make Constructors Private to Prohibit Derivation -- 102. Declare a Private operator new () to Prohibit Dynamic Allocation -- 103. Declare a Protected or Private Destructor to Prohibit Static or Automatic Allocation -- 104. Declare Single-Parameter Constructors as explicit to Avoid Unexpected Type Conversions -- 105. Use Default Arguments to Reduce the Number of Constructors -- 106. Do Not Overload Non-Virtual Methods in Subclasses -- 107. Declare Virtual Methods Protected and Call Them from Public Non-Virtual Methods -- 108. Keep Your Functions "const-correct" -- 109. Use Object Pointers and References in Class Declarations -- 7.7 Operators -- 110. Adhere to the Natural Semantics of Operators -- 111. Do Not Overload… -- 112. Invoke the Superclass Assignment Operator(s) in the Assignment Operator of a Subclass -- 113. Implement Copy-Safe and Exception-Safe Assignment Operators -- 114. Define Binary Operators Outside of a Class.

115. Implement a Boolean Operator in Terms of Its Opposite -- 7.8 Templates -- 116. Use Templates Instead of Macros to Create Parameterized Code -- 117. Do Not Use CV-Qualified Types as Template Parameters -- 7.9 Type Safety, Casting, and Conversion -- 118. Use C++ Casting Operators Instead of C-style Casts -- 119. Avoid Type Casting and Do Not Force Others to Use It -- 120. Use static_cast to Expose Non-Intuitive Implicit Conversions -- 121. Do Not Use reinterpret_cast in Portable Code -- 122. Only Use const_cast on "this" or When Dealing with Non-Const-Correct Code -- 123. Never Use dynamic_cast as a Substitute for Polymorphism -- 124. Use dynamic_cast to Restore Lost Type Information -- 125. Always Treat String Literals as const char* -- 126. Use C++ Streams Instead of stdio Functions for Type Safety -- 127. Test All Type Conversions -- 7.10 Initialization and Construction -- 128. Initialize All Variables -- 129. Do Not Rely on the Order of Initialization of Global Objects -- 130. Always Construct Objects in a Valid State -- 131. Initialize Member Variables in the Initializer List -- 132. Initialize Member Variables in the Order They are Declared -- 133. Indicate When the Declaration Order of Data Members is Significant -- 134. Always List any Superclass Constructors in the Initializer List of a Subclass Constructor -- 135. Do Not Call Virtual Functions in Constructors and Destructors -- 136. Declare and Initialize Static Variables within Functions -- 137. Zero Pointers after Deletion -- 138. Use the new and delete Operators Instead of malloc() and free() -- 7.11 Statements and Expressions -- 139. Do Not Rely on Operator Precedence in Complex Expressions -- 140. Use Block Statements in Control Flow Constructs -- 141. Do Not Test for Equality with True -- 142. Replace Repeated, Non-Trivial Expressions with Equivalent Methods.

143. Use size_t Variables for Simple Loop Iteration and Array Subscripts.