C + + Programming specification Brief notes

0. Know what should not be standardized
Naming conventions (Reference): classes, Functions, and enumerations likethis; Variable name likethis; member variable name likethis_; Macro Name
Like_this;

1. Compile cleanly at high warning level
2. Using Automatic Building System
3. Using version control system
4. Invest in Code review
5, an entity should have only one compact responsibility
6. Correct, simple and clear first
7, programming should know when and how to consider the scalability
8, do not carry out the immature optimization
9, do not carry out immature deterioration
10. Minimize global and shared data
11. Hiding information
12, know when and how to carry out concurrent programming
13. Ensure that resources are owned by the object, using explicit Raii and smart pointers
14, Ning to compile time and connection error, do not run-time error
15. Active use of const
16. Avoid using macros
17. Avoid using "magic number"
18. Declare variables as locally as possible
19. Always Initialize variables
20, avoid the function too long, avoid nesting too deep
21, avoid the initialization of cross-compilation unit dependencies
22, minimize the definition of dependency, avoid cyclic dependence
23. The head file should be self-sufficient
24. Always write an internal # include protector, never write an external # include protector
25. Correctly choose to pass parameters by value, (SMART) pointer, or reference
26. Maintaining the natural semantics of overloaded operators
27. Priority use of the standard form of arithmetic operators and assignment operators
28, preferential use of + + and--standard form, priority to call the prefix form
29. Consider overloading to avoid implicit type conversions
30. Avoid overloading &&, | | or, (comma)
31. Do not write code that relies on the order of the function parameter evaluation
32. Figure out what kind of writing is
33. Replace giant classes with small classes
34. Replace inheritance with combination
35. Avoid inheriting from classes that are not designed to be base classes
36, preferential provision of abstract interface
37, public inheritance can be replaced. Inheritance, not for reuse, but for reuse.
38, the implementation of security rewrite
39. Consider declaring the virtual function as non-public, declaring the public function as non-virtual
40. To avoid providing an implicit conversion
41. Set data members to private, except for non-behavioral aggregates
42. Do not disclose internal data
43. Use Pimpl wisely
44, preferential writing non-member non-friend function
45. Always provide new and delete together
46, if the provision of special class new, should provide all the standard form (normal, clothing and non-throwing)
47. Define and initialize member variables in the same order
48, in the constructor with the initialization in place of the assignment
49. Avoid calling virtual functions in constructors and destructors
50. Set the base class destructor to be public, virtual, or protected and non-virtual
51. Destructors, releases, and exchanges must never fail
52. Replication and destruction in a consistent manner
53. Explicitly enable or disable replication
54. Avoid slicing, consider cloning instead of copying in the base class
55, the use of the standard form of assignment
56, as long as feasible, provide will not fail the swap (and to provide correctly)
57. Place the type and its non-member function interfaces in the same namespace
58. The types and functions should be placed in separate namespaces unless you want them to work together
59. Do not write namespace using before header file or # include
60. To avoid allocating and freeing memory in different modules
61. Do not define entities with links in the header file
62. Do not allow exceptions to propagate across block boundaries
63. Use a well-portable type in the interface of the module
64. Rational combination of static polymorphism and dynamic polymorphism
65. Intentional Explicit customization
66, do not special function template
67. Do not unintentionally write code that is not generic
68. Extensive use of assertions to record internal assumptions and invariant
69, establish a reasonable error handling strategy, and strictly abide by
70. Difference Error and non-error
71. Design and write error-Safe code
72, priority to use Exception Report error
73. Throw by value, capture by reference
74. Correct reporting, processing and conversion errors
75, avoid the use of abnormal norms
76. Use vectors by default, otherwise, select other suitable containers
77. Replacing arrays with vectors and strings
78. Exchanging data with vectors (and string::c_str) and non-C++API
79. Store only values and smart pointers in the container
80. The way to replace other extended sequences with push_back
81, multi-use range operation, less single element operation
82. Use accepted idioms to really compress capacity and really delete elements
83, using the STL implementation with inspection
84, using algorithm calls instead of hand-written loops
85, using the correct STL lookup algorithm
86, using the correct STL sorting algorithm
87. Make the predicate a pure function
88, algorithm and comparator parameters should be used more function object less function
89. Correctly write function objects
90, avoid the use of type branches, multi-use polymorphic
91. Dependency type, not its representation
92. Avoid using reinterpret_cast
93. Avoid using static_cast on the pointer
94. Avoid Casting const
95. Do not use C-style casts
96, do not memcpy operation or memcmp operation of non-pod
97. Do not use joint re-interpretation representations
98. Do not use variable length parameters (...). ）
99. Do not use invalid object, do not use unsafe function
100. Do not deal with arrays in many states

C + + Programming specification Brief notes