Name | Checked | Synopsis |
---|
ARR38-C
|
 |
Guarantee that library functions do not form invalid pointers |
C.127
|
 |
A class with a virtual function should have a virtual or protected destructor |
CFL#001
|
 |
Statements following a case label shall be terminated by a statement that exits the switch statement |
CFL#002
|
 |
All switch statements shall have a default label as the last case label |
CFL#003
|
 |
An else sub-statement of an if statement shall not be an if statement without an else part |
CFL#004
|
 |
Do not use goto |
CFL#005
|
 |
Do not access a modified object more than once in an expression |
CFL#006
|
 |
Do not apply sizeof to an expression with side-effects |
CFL#007
|
 |
Do not change a loop variable inside a for loop block |
CFL#008
|
 |
Always use inclusive lower limits and exclusive upper limits |
CFL#009
|
 |
Never use continue in a nested loop |
CFL#010
|
 |
Never use break to exit a loop |
CFL#011
|
 |
The test condition in control statements shall be a non-assignment expression |
CFL#012
|
|
Update loop variables close to where the loop condition is specified |
CFL#013
|
 |
All flow control primitives (if, else, while, for, do, switch) shall be followed by a block, even if it is empty |
CFL#014
|
 |
Do not return from unexpected locations |
CFL#015
|
 |
The definition of a void function shall not end with a return statement |
CFL#016
|
 |
Do not have overly complex functions |
CFL#017
|
 |
Do not make explicit comparisons to true or false |
CFL#018
|
 |
Use range-based for loops if possible |
CFL#019
|
 |
Use explicit parentheses when using multiple different operators in an expression |
CFL#020
|
 |
Control should not reach the end of a non-void function without returning a value |
CFL#021
|
 |
Use prefix instead of postfix versions of ++ and -- operators for non-simple types |
CFL#022
|
 |
Apply sizeof to an object rather than to its type |
CFL#023
|
|
Do not use selection statements (if, switch) instead of a simple assignment or initialization |
CFL#024
|
 |
A statement must have a side-effect, i.e., it must do something. |
CFL#025
|
 |
Use a reference to a range based loop "auto" variable if it is modified in its body |
COM#001
|
 |
Every file that contains source code must be documented with an introductory comment that provides information on the file name and its contents |
COM#002
|
 |
All files must include copyright information |
COM#003
|
 |
All comments are to be written in English |
COM#004
|
 |
Use // for comments |
COM#005
|
 |
Do not leave commented-out code in the source file |
COM#007
|
|
Use //====== for block comments at global scope |
CON#001
|
 |
Make unsafe type conversions explicit rather than implicit |
CON#002
|
 |
Do not cast away const |
CON#003
|
 |
Avoid explicit type conversions (casts) if possible |
CON#004
|
 |
Use the new cast operators (static_cast, const_cast, dynamic_cast, and reinterpret_cast) instead of the C-style casts |
CON#005
|
|
Declare a data member mutable if it must be modified by a const member function and has no influence on the state of the program |
CON#006
|
|
Prefer static_cast over reinterpret_cast if possible |
CON#007
|
 |
Do not convert implicitly from a boolean type to a non-boolean type, and vice versa. |
CON#008
|
 |
Don't take the address of an array |
CON#009
|
 |
Don't compare an address to null |
CP.42
|
 |
Don’t wait without a condition |
DCL50-CPP
|
 |
Do not define a C-style variadic function |
ENV33-C
|
 |
Do not call system() |
ERR#001
|
 |
Do not let destructors throw exceptions |
ERR#002
|
|
Constructors of types thrown as exceptions shall not themselves throw exceptions |
ERR#003
|
|
Before letting any exceptions propagate out of a member function, make certain that the class invariant holds and, if possible, leave the state of the object unchanged |
ERR#004
|
|
Check the fault codes that may be received from library functions/methods even if these functions/methods seem foolproof |
ERR#005
|
 |
Check for all errors reported from functions |
ERR#006
|
 |
Don't use exception specifications, but do use noexcept when applicable |
ERR#007
|
|
Throw exceptions only when a function fails to do what it is expected to do |
ERR#008
|
|
Do not throw exceptions as a way of reporting uncommon values from a function |
ERR#009
|
|
Use objects to manage resources |
ERR#010
|
|
A resource managed by an object must be released by the object's destructor |
ERR#012
|
 |
Throw only objects of class type |
ERR#013
|
|
Group related exception types by using inheritance |
ERR#014
|
 |
Do not catch objects by value |
ERR33-C
|
 |
Detect and handle standard library errors |
ERR54-CPP
|
 |
Catch handlers should order their parameter types from most derived to least derived |
ERR#015
|
|
Always catch exceptions the caller is not supposed to know about |
ERR#016
|
|
Do not catch exceptions you are not supposed to know about |
ERR#017
|
 |
A catch-all clause must do a rethrow |
EXP34-C
|
 |
Do not dereference null pointers |
EXP53-CPP
|
 |
Do not read uninitialized memory |
EXT01-CPP
|
 |
The called function is unsafe for security related code |
EXT02-CPP
|
 |
non-constant printf format string may be susceptible to format string attacks |
EXT03-CPP
|
 |
Calling a function which may pose a security risk if it is used inappropriately |
EXT04-CPP
|
 |
Using an insecure temporary file creation function |
EXT05-CPP
|
 |
A user-land pointer is dereferenced without safety checks in the kernel |
FIO30-C
|
 |
Exclude user input from format strings |
FIO34-C
|
 |
Distinguish between characters read from a file and EOF or WEOF |
FIO37-C
|
 |
Do not assume that fgets() or fgetws() returns a nonempty string when successful |
FIO45-C
|
 |
Avoid TOCTOU race conditions while accessing files |
GEN#001
|
|
If functionality is supported in a standard C++ class library, use this library when feasible |
GEN#002
|
|
Company C++ code shall be clearly separated from 3rd party code |
GEN#003
|
 |
Avoid pointer arithmetic . The only operators allowed on pointers are "=", "==", "!=", " ->", "[ ]" (for arrays) and the unary "*". |
I.2
|
 |
Avoid non-const global variables |
INT#001
|
 |
Non-copy-constructors that can be called with one argument shall be declared as explicit |
INT#002
|
 |
Declare non-constant data members private |
INT#003
|
|
Only declare public or protected accessors for data members that must be accessible |
INT#004
|
 |
Always specify the return type of a method/function explicitly |
INT#005
|
|
Do not change the formal parameters order, just to be able to have parameter defaults |
INT#006
|
 |
A member function that should not change the state of the object shall be declared const |
INT#007
|
|
If the behavior of an object is dependent on data outside the object, this data is not to be modified by const methods |
INT#008
|
 |
Use constant references (const &) instead of call-by-value, unless using a basic data type, a simple object or a pointer |
INT#009
|
|
Do not use special values for don't care parameters |
INT#010
|
|
Use operator overloading sparingly and in a uniform manner |
INT#011
|
 |
If you overload one of a closely related set of operators, then you should overload the whole set and preserve the same invariants that exist for built-in types |
INT#012
|
 |
Avoid multiple definition of overloaded methods/functions in conjunction with the instantiation of a class template |
INT#013
|
 |
Avoid methods and functions with many arguments |
INT#014
|
|
Use a parameter of pointer type if the function stores the address or passes it to a function that does |
INT#015
|
|
All variants of an overloaded member function shall be used for the same purpose and have similar behavior |
INT#016
|
 |
Make simple functions inline |
INT#017
|
 |
Do not use conversion member functions or user-defined cast operators |
INT#018
|
 |
Pass arguments of built-in types by value unless the function should modify them |
INT#019
|
 |
Once a default parameter value is defined, the value may never be changed |
INT#020
|
 |
Pass arguments of non-simple types by reference or pointer |
INT#021
|
 |
Pass arguments of class types by reference or pointer if the class is meant as a public base class |
INT#022
|
 |
A pointer or reference parameter should be declared const if the function does not change the object bound to it |
INT#023
|
 |
The copy constructor and the copy assignment operator shall always have a const parameter |
INT#024
|
|
A member function that gives non-const access to the representation of an object must not be declared const |
INT#025
|
|
Do not let const member functions change the state of the program |
INT#026
|
 |
In a derived class, if you need to override one of a set of the base class's overloaded virtual member functions, then you must override the whole set, or use using-declarations to bring all of the functions in the base class into the scope of the derived class |
INT#027
|
 |
If you override one of the base class's virtual functions, then you shall use the "override" or "final" keyword |
INT#028
|
 |
Supply default arguments with the function's declaration, not with the function's definition |
INT#029
|
|
Use built-in boolean type where possible |
INT#030
|
 |
Do not misuse a pointer when an array is requested |
MEM50-CPP
|
 |
Do not access freed memory |
MEM56-CPP
|
 |
Do not store an already-owned pointer value in an unrelated smart pointer |
MSC30-C
|
 |
Do not use the rand() function for generating pseudorandom numbers |
MSC33-C
|
 |
Do not pass invalid data to the asctime() function |
MSC51-CPP
|
 |
Ensure your random number generator is properly seeded |
NAM#001
|
|
Use US English names for identifiers |
NAM#002
|
 |
Do not use identifiers which begin with an underscore ('_') followed by a capital |
NAM#003
|
 |
The names of user defined types, enumerators, typedefs, typenames and class templates are in PascalCase |
NAM#004
|
 |
In names which consist of more than one word, the words are written together and each word that follows the first is begun with an uppercase letter |
NAM#005
|
 |
The names of data members and member functions are in PascalCase |
NAM#006
|
 |
The names of formal arguments to methods/functions should be specified and should be the same both in the declaration and in the definition |
NAM#007
|
|
Accessor method names should correspond with the attribute being accessed |
NAM#008
|
 |
Do not use identifiers that contain two or more underscores in a row |
NAM#009
|
|
Use meaningful names |
NAM#010
|
|
Be consistent when naming identifiers |
NAM#011
|
|
Names should not include abbreviations that are not generally accepted |
NAM#012
|
|
Prefix macros in include files with their module's basename in uppercase, followed by an underscore and further uppercase characters |
NAM#013
|
|
Prefixes for exported functions, structures, enumerations and macros consist of unit id and optionally module id |
NAM#014
|
 |
The names of internal or local variables and internal functions are in camelCase |
NAM#015
|
 |
Use Pascal and Camel casing for naming indentifiers |
OAL#001
|
|
Only customize the memory management for a class if memory management is an unacceptably large part of the allocation and deallocation of free store objects of that class |
OAL#002
|
|
If you overload operator delete, it shall be prepared to accept a null pointer |
OAL#003
|
 |
If you overload operator new for a class, you should have a corresponding operator delete |
OAL#004
|
|
In case allocated memory has to be deallocated later by someone else, use a unique_ptr with move semantics |
OAL#005
|
 |
Assign a new value to a pointer that points to deallocated memory |
OAL#006
|
 |
delete shall be used only with new |
OAL#007
|
 |
Don't mix new and delete for array and non-array types |
OAL#008
|
 |
Do not use "delete" to delete raw pointers inside smart pointers |
OAL#009
|
 |
Do not overload the global operator new or the global operator delete |
OAL#010
|
 |
Do not overload the new and/or delete operators |
OAL#012
|
 |
Don't use auto_ptr, use unique_ptr instead |
OAL#013
|
 |
Use std::make_shared instead of constructing a shared_ptr from a raw pointer |
OAL#015
|
 |
Use nullptr instead of 0 or NULL for pointers |
OAL#017
|
 |
Use smart pointers from the standard library |
OAL#018
|
 |
Don't forget to give scoped variables a name |
OAL#019
|
 |
Don't use the default constructor when creating a local unique_lock |
OLC#001
|
 |
If objects of a class should never be copied, then the copy constructor and the copy assignment operator shall be declared as deleted functions |
OLC#002
|
 |
Copy assignment operators shall be implemented with the swap idiom |
OLC#003
|
 |
A function must never return, or in any other way give access to, references or pointers to local variables outside the scope in which they are declared |
OLC#004
|
 |
Every variable of a built-in type that is declared is to be given a value before it is used |
OLC#005
|
 |
Don't call virtual functions in constructors and destructors |
OLC#006
|
 |
Variables and types are to be declared with the smallest possible scope |
OLC#007
|
|
Use direct- instead of copy-initialization in object declarations of class type |
OLC#008
|
|
If it must be possible to instantiate a class via a default constructor, always define a default constructor which explicitly initializes data members |
OLC#009
|
 |
Literals should be used only on the definition of constants and enumerations |
OLC#010
|
 |
Declare each variable in a separate declaration statement |
OLC#011
|
|
Avoid unnecessary copying of objects that are costly to copy |
OLC#012
|
 |
Do not initialise static variables with other (external) static variables |
OLC#013
|
 |
Data members do not have to be reset in a destructor |
OLC#014
|
|
Minimize the number of temporary objects that are created as return values from methods/functions or as arguments to methods/functions |
OLC#015
|
 |
A variable must be initialized within the scope of its usage |
OLC#016
|
 |
Do not re-declare a visible name in a nested scope |
OLC#017
|
 |
Initialize all data members of built-in types |
OLC#018
|
 |
Let the order of the initializer list be: first base class constructor(s), then data members in the same order of declaration as in the header file |
OLC#019
|
 |
If passing the "this" pointer to a constructor initializer list, be aware that the object is not yet fully constructed |
OLC#020
|
 |
Don't pass member variables to the base class in the constructor's initializer list |
OLC#021
|
 |
Initialize atomic variables correctly |
OOP#001
|
 |
If you define or =delete any copy, move, or destructor function, define or =delete them all |
OOP#002
|
|
A public method must never return a non-const reference or pointer to member data |
OOP#003
|
|
A public method must never return a non-const reference or pointer to data outside an object, unless the object shares the data with other objects |
OOP#004
|
 |
Derive from more than one base class with the same parent with care |
OOP#005
|
|
Do use references for associations with cardinality '1' whenever possible |
OOP#006
|
 |
A function should not return a raw pointer |
OOP#007
|
|
Selection statements (if-else and switch) should be used when the control flow depends on an object's value; dynamic binding should be used when the control flow depends on the object's type |
OOP#008
|
 |
Encapsulate global variables and constants, enumerated types, and typedefs in a class or in a namespace |
OOP#009
|
|
Avoid inheritance for parts-of relations |
OOP#010
|
 |
Avoid multiple inheritance |
OOP#011
|
 |
Never redefine an inherited non-virtual method |
OOP#012
|
|
Use C++ to describe preconditions, postconditions, exceptions, and class invariants |
OOP#013
|
 |
A base class destructor should be either public and virtual, or protected and non-virtual |
OOP#014
|
|
Document the interface of template parameters |
OOP#015
|
 |
Friends of a class should be avoided |
OOP#016
|
|
Specify functions using preconditions, postconditions, exceptions; specify classes using invariants |
OOP#017
|
|
It shall be possible to use a pointer or reference to an object of a derived class wherever a pointer or reference to a public base class object is used |
OOP#018
|
 |
When overriding a (virtual) function from a base class, the derived class should give the same const modifier to the function. |
OPT#001
|
|
Avoid duplicated code and data |
OPT#002
|
|
Optimize code only if you know that you have a performance problem. Think twice before you begin |
OPT#003
|
 |
Avoid the usage of inline methods/functions |
ORG#001
|
 |
Enclose all code in header files within include guards |
ORG#002
|
|
Each file shall be self-contained |
ORG#003
|
 |
From a source file include only header files |
ORG#004
|
|
Classes that are only accessed via pointers (*) or references (&) shall not be included as header files |
ORG#005
|
|
Each file shall directly include each header file upon which declarations it directly depends |
ORG#006
|
 |
C++ header files have the extension .h, .hpp or .hxx |
ORG#007
|
 |
C++ source files have the extension .cpp |
ORG#008
|
|
Place non-portable code in a special file so that it may be easily located when porting code from one architecture/environment to another |
ORG#009
|
|
Avoid unnecessary inclusion |
ORG#010
|
 |
Do not let assertions change the state of the program |
ORG#011
|
 |
Everything must reside in a namespace |
ORG#012
|
 |
Never put "using namespace" in header files |
ORG#013
|
 |
Don't put definitions in header files |
PCA#001
|
 |
Don't use malloc, calloc, realloc, free and cfree for memory management |
PCA#002
|
 |
Do not assume that an enumerator has a specific value |
PCA#003
|
 |
Use overloaded functions and chained function calls instead of functions with an unspecified number of arguments |
PCA#004
|
 |
Do not use structures as replacement for classes |
PCA#005
|
 |
Use the iostream library instead of C-style I/O |
PCA#006
|
 |
Do not use setjmp and longjmp |
PCA#007
|
 |
Use overloaded functions instead of default arguments |
PCA#008
|
 |
Do not redefine keywords |
PCA#009
|
 |
Use an array class instead of built-in arrays |
PCA#010
|
 |
Do not use unions |
PCA#011
|
 |
Do not use bit-fields |
PCA#012
|
 |
Do not use obsolete or redundant keywords |
PCA#013
|
 |
Do not use trigraphs or alternative tokens |
PCA#014
|
 |
Only use the this. construction to avoid a name clash |
PCA#015
|
 |
Do not combine a class, enum or struct definition with typedef |
PCA#016
|
 |
Use enum classes instead of old-style enums |
PCA#017
|
 |
Don't compare unrelated enumerations |
PCA#018
|
 |
Use functionality from the std library if possible |
PCA#019
|
 |
Use string_view correctly |
POR#001
|
 |
Never use absolute file paths |
POR#002
|
|
Do not assume that an int and a long have the same size |
POR#003
|
 |
Do not assume that a char is signed or unsigned |
POR#004
|
 |
Do not cast a pointer to a shorter quantity to a pointer to a longer quantity |
POR#005
|
 |
Do not assume that pointers and integers have the same size |
POR#006
|
 |
Use explicit type conversions for arithmetic using signed and unsigned values |
POR#007
|
|
Do not assume that you know how an instance of a data type is represented in memory |
POR#008
|
|
Do not depend on underflow or overflow functioning in any special way |
POR#009
|
|
Do not assume that longs, floats, doubles or long doubles may begin at arbitrary addresses |
POR#010
|
|
Do not assume that the operands in an expression are evaluated in a definite order, unless the order is specified in the language |
POR#011
|
|
Do not assume that you know how the invocation mechanism for a method or function is implemented |
POR#012
|
|
Do not assume that static objects are initialized in any special order when they are spread over multiple source files |
POR#014
|
|
Do not assume that a short is 16-bits |
POR#015
|
|
Do not assume that a long is 32-bits |
POR#016
|
|
Do not assume that the size of an enumeration is the same for all platforms |
POR#017
|
|
Do not depend on undefined, unspecified, or implementation-defined parts of the language |
POR#018
|
 |
Avoid the use of #pragma directives |
POR#019
|
 |
Header file names shall always be treated as case-sensitive |
POR#020
|
|
Do not make assumptions about the exact size or layout in memory of an object |
POR#021
|
 |
Avoid the use of conditional compilation |
POR#022
|
|
Make sure all conversions from a value of one type to another of a narrower type do not slice off significant data |
POR#023
|
|
Use typedefs or classes to hide the representation of application-specific data types |
POR#024
|
|
Use macros to prevent the use of unsupported keywords |
POR#025
|
 |
Floating point values shall not be compared using the == or != operators |
POR#026
|
|
Only one #include directive should be needed when using a template |
POR#027
|
|
Do not rely on partial instantiation of templates |
POR#028
|
 |
Always return a value from main |
POR#029
|
 |
Do not depend on the order of evaluation of arguments to a function |
POR#030
|
|
Both operands of the remainder operator shall be positive |
POR#031
|
 |
Do not depend on implementation defined behavior of shift operators for built-in types |
POR#032
|
 |
Use nullptr instead of 0 or NULL for a null pointer |
POR#033
|
 |
Do not make assumptions on the size of int |
POR#034
|
 |
Avoid using shift operations instead of arithmetic operations |
POR#035
|
 |
Headers supplied by external libraries go in <> brackets; all other headers go in "" quotes |
POR#036
|
|
If an object is created using a default constructor, then don't use parenthesis in the declaration |
POR#037
|
 |
Avoid the use of #pragma warning directive. |
POR#038
|
|
Make sure that the sizes and types of functions are well-defined if exported to other languages |
PRE#001
|
 |
Do not define macros instead of constants, enums, or type definitions |
PRE#002
|
 |
Use parentheses around macro and macro parameters |
PRE#003
|
|
Be aware of side-effects when using macros |
PRE#004
|
 |
Do not use the preprocessor directive #define to obtain more efficient code; instead, use inline or template methods/functions |
R.11
|
 |
Avoid calling new and delete explicitly |
R.22
|
 |
Use make_shared() to make shared_ptrs |
R.23
|
 |
Use make_unique() to make unique_ptrs |
R.33
|
 |
Take a unique_ptr<widget>& parameter to express that a function reseats the widget |
R.34
|
 |
Take a shared_ptr<widget> parameter to express shared ownership |
R.35
|
 |
Take a shared_ptr<widget>& parameter to express that a function might reseat the shared pointer |
R.37
|
 |
Do not pass a pointer or reference obtained from an aliased smart pointer |
STA#001
|
|
If a variable is not intended to change, make it a constant |
STA#002
|
 |
Objects with static storage duration should be declared only within the scope of a class, function, or unnamed namespace |
STA#003
|
|
Document how objects with class or global scope are initialized |
STR31-C
|
 |
Guarantee that storage for strings has sufficient space for character data and the null terminator |
STR32-C
|
 |
Do not pass a non-null-terminated character sequence to a library function that expects a string |
STR38-C
|
 |
Do not confuse narrow and wide character strings and functions |
STR50-CPP
|
 |
Guarantee that storage for strings has sufficient space for character data and the null terminator |
STR51-CPP
|
 |
Do not attempt to create a std::string from a null pointer |
STY#001
|
 |
The public, protected, and private sections of a class shall be declared in that order |
STY#002
|
|
Always use parentheses to clarify the order of expression evaluation |
STY#003
|
|
Use a consistent order in various kinds of class members |
STY#004
|
 |
Access static members via classes using the :: operator, instead of via objects using the . or -> operator |
STY#005
|
|
The indentation must be 4 spaces |
STY#006
|
|
In a class definition use separate public, protected, and private sections for type definitions, constants, enumerations, nested classes, friends, methods and data members |
STY#007
|
 |
Do not write multiple statements per line |
STY#008
|
 |
Always write the left parentheses directly after a method/function name |
STY#009
|
 |
Braces ("{}") which enclose a block are to be placed in the same column, on separate lines directly before and after the block |
STY#010
|
|
Use the specified method/function declaration and definition layout |
STY#011
|
 |
In declarations, attach the & or * token to the type name instead of the object name |
STY#012
|
 |
Do not use spaces around . or ->, nor between unary operators and operands |
STY#013
|
 |
Do use spaces before and after binary and ternary operators. |
STY#014
|
 |
Do not use spaces directly before and after brackets |
STY#015
|
|
Do use spaces after punctuation marks and do not use spaces before punctuation marks |
STY#016
|
|
Do not use additional parentheses in a return statement |
STY#017
|
 |
If a method/function has no formal parameter, do not use the keyword void |
STY#018
|
 |
The keyword typename shall be used to introduce a type parameter to a template |
STY#019
|
 |
Pointers to pointers should whenever possible be avoided |
STY#020
|
 |
Use std::function instead of function pointers |
STY#021
|
|
Do not mix coding styles within a group of closely related classes or within a module |
STY#022
|
 |
The names of macros are in uppercase |
STY#023
|
|
The name of a class type used for exceptions is suffixed with _EXC, Exception or Exc |
STY#024
|
 |
The name of an #include guard shall contain at least the name of the header file. |
STY#025
|
 |
Do not use letters that can be mistaken for digits, and vice versa |
STY#026
|
|
When accessing global identifiers, use :: |
STY#027
|
 |
Do not use tabs in source code |
STY#028
|
 |
The names of parameters to functions shall be specified in both the function declaration and the function definition |
STY#029
|
 |
Always provide an access specifier for class members |
STY#030
|
 |
The keyword struct shall only be used to declare a plain old data struct type |
STY#031
|
 |
Switch labels and statements should be on seperate lines |