The Elements of C++ Style
The Elements of C++ Style, first published in 2004, is for all C++ practitioners, especially for those working in teams where consistency is critical. Just as Strunk and White's The Elements of Style provides rules of usage for writing in the English language, this text furnishes a set of rules...
Saved in:
| Main Authors: | , , , |
|---|---|
| Format: | eBook Book |
| Language: | English |
| Published: |
Cambridge, U.K
Cambridge University Press
16.02.2004
|
| Edition: | 1 |
| Subjects: | |
| ISBN: | 9780521893084, 0521893089 |
| Online Access: | Get full text |
| Tags: |
Add Tag
No Tags, Be the first to tag this record!
|
Table of Contents:
- 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
- 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
- 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
- 142. Replace Repeated, Non-Trivial Expressions with Equivalent Methods
- 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
- 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