# Subject G1149 If a source or header file refers to a symbol defined elsewhere, the file should directly include a header file which properly intends to provide a declaration or definition of that symbol. G1150 In general, every .cc file should have an associated .h file. There are some common exceptions, such as unit tests and small .cc files containing just a main() function. G1151 Header files should be self-contained (compile on their own) and end in .h. G1152 When a header declares inline functions or templates that clients of the header will instantiate, the inline functions and templates must also have definitions in the header, either directly or in files it includes. G1153 All header files should have #define guards to prevent multiple inclusion. The format of the symbol name should be <PROJECT>_<PATH>_<FILE>_H_. G1154 Avoid using forward declarations where possible. Instead, include the headers you need. G1155 Define functions inline only when they are small, say, 10 lines or fewer. G1156 Include headers in the following order: Related header, C system headers, C++ standard library headers, other libraries' headers, your project's headers. G1157 All of a project's header files should be listed as descendants of the project's source directory without use of UNIX directory aliases . (the current directory) or .. (the parent directory). G1158 Do not use using-directives (e.g., using namespace foo). G1159 Do not use inline namespaces. G1160 Do not declare anything in namespace std, including forward declarations of standard library classes. G1161 When definitions in a .cc file do not need to be referenced outside that file, give them internal linkage by placing them in an unnamed namespace or declaring them static. G1162 Do not use either of these constructs in .h files. G1163 Do not use a class simply to group static members. G1164 If you define a nonmember function and it is only needed in its .cc file, use internal linkage to limit its scope. G1165 Objects with static storage duration are forbidden unless they are trivially destructible. G1166 Use of dynamic initialization for static class member variables or variables at namespace scope is discouraged G1167 Avoid virtual method calls in constructors, and avoid initialization that can fail if you can't signal an error. G1168 Do not define implicit conversions. Use the explicit keyword for conversion operators and single-argument constructors. G1169 A class's public API must make clear whether the class is copyable, move-only, or neither copyable nor movable. G1170 To eliminate the risk of slicing, prefer to make base classes abstract, by making their constructors protected, by declaring their destructors protected, or by giving them one or more pure virtual member functions. G1171 Prefer to avoid deriving from concrete classes. G1172 (struct) All fields must be public. G1173 When using inheritance, make it public. G1174 Limit the use of protected to those member functions that might need to be accessed from subclasses. G1175 Do not use virtual when declaring an override. G1176 Do not use user-defined literals. G1177 Define operators only on your own types. More precisely, define them in the same headers, .cc files, and namespaces as the types they operate on. G1178 If possible, avoid defining operators as templates, because they must satisfy this rule for any possible template arguments. G1179 If you define an operator, also define any related operators that make sense, and make sure they are defined consistently. G1180 Prefer to define non-modifying binary operators as non-member functions. G1181 Do not overload &&, ||, , (comma), or unary &. G1182 Make classes' data members private, unless they are constants. G1183 Group similar declarations together, placing public parts earlier. G1184 Within each section, prefer grouping similar kinds of declarations together G1185 Do not put large method definitions inline in the class definition. G1186 Non-optional input parameters should usually be values or const references G1187 Use non-const pointers to represent optional outputs and optional input/output parameters. G1188 When ordering function parameters, put all input-only parameters before any output parameters. G1189 If a function exceeds about 40 lines, think about whether it can be broken up without harming the structure of the program. G1190 Default arguments are banned on virtual functions, where they don't work properly, and in cases where the specified default might not evaluate to the same value depending on when it was evaluated. G1191 Use rvalue references only in certain special cases. G1192 Friend classes and functions should only be defined in the same file G1193 Avoid using run-time type information (RTTI). G1194 Use C++-style casts G1195 Use the prefix form (++i) of the increment and decrement operators unless you need postfix semantics. G1196 For a function parameter passed by value, const has no effect on the caller, thus is not recommended in function declarations. G1197 Of the built-in C++ integer types, the only one used is int. If a program needs an integer type of a different size, use an exact-width integer type from <cstdint>, such as int16_t. G1198 If your code is a container that returns a size, be sure to use a type that will accommodate any possible usage of your container. G1199 Use care when converting integer types. G1200 Avoid defining macros, especially in headers; prefer inline functions, enums, and const variables. G1201 Name macros with a project-specific prefix. G1202 Use nullptr for pointers, and '\0' for chars (and not the 0 literal). G1203 Prefer sizeof(varname) to sizeof(type). G1204 Use return type deduction in small functions G1205 Do not use return type deduction for public functions G1206 Use comment to indicate field name for structured bindings G1207 Use CTAD with template providing at least one explicit deduction guide. G1208 Use designed initializers in the same order as the fields in struct definition G1209 Use default capture by value ([=]) only as a means of binding a few variables for a short lambda, where the set of captured variables is obvious at a glance G1210 Use capture by value explicitly or capture by reference for non-static class members in non-static member functions G1211 Don't introduce new names in captures G1212 only allow a subset of Boost features G1213 Don't use <ratio> G1214 Don't use <cfenv> <fenv.h> G1215 Don't use <filesystem> G1216 Don't use nonstandard extensions G1269 A class should have only one other friend class