Skip to end of metadata
Go to start of metadata

MISRA C 2012 (58 / 166)

NumberDescriptionDone
Dir 4.3Assembly language shall be encapsulated and isolated
  •  
Dir 4.4Sections of code should not be "commented out"
  •  
Dir 4.5Identifiers in the same name space with overlapping visibility should be typographically unambiguous
  •  
Dir 4.6typedefs that indicate size and signedness should be used in place of the basic numerical types
  •  
Dir 4.7If a function returns error information, then that error information shall be tested
  •  
Dir 4.8If a pointer to a structure or union is never dereferenced within a translation unit, then the implementation of the object should be hidden
  •  
Dir 4.9A function should be used in preference to a function-like macro where they are interchangeable
  •  
Dir 4.10Precautions shall be taken in order to prevent the contents of a header file being included more than once
  •  
Dir 4.11The validity of values passed to library functions shall be checked
  •  
Dir 4.12Dynamic memory allocation shall not be used
  •  
Dir 4.13Functions which are designed to provide operations on a resource should be called in an appropriate sequence
  •  
Dir 4.14The validity of values received from external sources shall be checked
  •  
Rule 1.1The program shall contain no violations of the standard C syntax and constraints, and shall not exceed the implementation's translation limits
  •  
Rule 1.2Language extensions should not be used
  •  
Rule 1.3There shall be no occurrence of undefined or critical unspecified behavior
  •  
Rule 2.1A project shall not contain unreachable code
  •  
Rule 2.2There shall be no dead code
  •  
Rule 2.3A project should not contain unused type declarations
  •  
Rule 2.4A project should not contain unused tag declarations
  •  
Rule 2.5A project shall not contain unused macro declarations
  •  
Rule 2.6A function should not contain unused label declarations
  •  
Rule 2.7There should be no unused parameters in functions
  •  
Rule 3.1The character sequences /* and // shall not be used within a comment
  •  
Rule 3.2Line-splicing shall not be used in // comments
  •  
Rule 4.1Octal and hexadecimal escape sequences shall be terminated
  •  
Rule 4.2Trigraphs should not be used
  •  
Rule 5.1External identifiers shall be distinct
  •  
Rule 5.3An identifier declared in an inner scope shall not hide an identifier declared in an outer scope
  •  
Rule 5.4Macro identifiers shall be distinct
  •  
Rule 5.5Identifiers shall be distinct from macro names
  •  
Rule 5.6A typedef name shall be a unique identifier
  •  
Rule 5.7A tag name shall be a unique identifier
  •  
Rule 5.8Identifiers that define objects or functions with external linkage shall be unique
  •  
Rule 5.9Identifiers that define objects or functions with internal linkage should be unique
  •  
Rule 6.1Bit-fields shall only be declared with an appropriate type
  •  
Rule 6.2Single-bit named bit fields shall not be of a signed type
  •  
Rule 7.1Octal constants shall not be used
  •  
Rule 7.2A "u" or "U" suffix shall be applied to all integer constants that are represented in an unsigned type
  •  
Rule 7.3The lowercase character "l" shall not be used in a literal suffix
  •  
Rule 7.4A string literal shall not be assigned to an object unless the object's type is "pointer to const-qualified char"
  •  
Rule 8.1Types shall be explicitly specified
  •  
Rule 8.2Function types shall be in prototype form with named parameters
  •  
Rule 8.3All declarations of an object or function shall use the same names and type qualifiers
  •  
Rule 8.4A compatible declaration shall be visible when an object or function with external linkage is defined
  •  
Rule 8.5An external object or function shall be declared once in one and only one file
  •  
Rule 8.6An identifier with external linkage shall have exactly one external definition
  •  
Rule 8.7Functions and objects should not be defined with external linkage if they are referenced in only one translation unit
  •  
Rule 8.8The static storage specifier shall be used in all declarations of objects and functions that have internal linkage
  •  
Rule 8.9An object should be defined at block scope if its identifier only appears in a single function
  •  
Rule 8.10An inline function shall be declared with the static storage class
  •  
Rule 8.11When an array with external linkage is declared, its size should be explicitly specified
  •  
Rule 8.12Within an enumerator list, the value of an implicitly-specified enumeration constant shall be unique
  •  
Rule 8.13A pointer should point to a const-qualified type whenever possible
  •  
Rule 8.14The restrict type qualifier shall not be used
  •  
Rule 9.1The value of an object with automatic storage duration shall not be read before it has been set
  •  
Rule 9.2The initializer for an aggregate or union shall be enclosed in braces
  •  
Rule 9.3Arrays shall not be partially initialized
  •  
Rule 9.4An element of an object shall not be initialized more than once
  •  
Rule 9.5Where designated initializers are used to initialize an array object the size of the array shall be specified explicitly
  •  
Rule 10.1Operands shall not be of an inappropriate essential type
  •  
Rule 10.2Expressions of essentially character type shall not be used inappropriately in addition and subtraction operations
  •  
Rule 10.3The value of an expression shall not be assigned to an object with a narrower essential type or of a different essential type category
  •  
Rule 10.4Both operands of an operator in which the usual arithmetic conversions are performed shall have the same essential type category
  •  
Rule 10.5The value of an expression should not be cast to an inappropriate essential type
  •  
Rule 10.6The value of a composite expression shall not be assigned to an object with wider essential type
  •  
Rule 10.7If a composite expression is used as one operand of an operator in which the usual arithmetic conversions are performed then the other operand shall not have wider essential type
  •  
Rule 10.8The value of a composite expression shall not be cast to a different essential type category or a wider essential type
  •  
Rule 11.1Conversions shall not be performed between a pointer to a function and any other type
  •  
Rule 11.2Conversions shall not be performed between a pointer to an incomplete type and any other type
  •  
Rule 11.3A cast shall not be performed between a pointer to object type and a pointer to a different object type
  •  
Rule 11.4A conversion should not be performed between a pointer to object and an integer type
  •  
Rule 11.5A conversion should not be performed from a pointer to void into pointer to object
  •  
Rule 11.6A cast shall not be performed between pointer to void and an arithmetic type
  •  
Rule 11.7A cast shall not be performed between pointer to object and a non-integer arithmetic type
  •  
Rule 11.8A cast shall not remove any const or volatile qualification from the type pointed to by a pointer
  •  
Rule 11.9The macro NULL shall be the only permitted form of integer null pointer constant
  •  
Rule 12.1The precedence of operators within expressions should be made explicit
  •  
Rule 12.2The right hand operand of a shift operator shall lie in the range zero to one less than the width in bits of the essential type of the left hand operand
  •  
Rule 12.3The comma operator should not be used
  •  
Rule 12.4Evaluation of constant expressions should not lead to unsigned integer wrap-around
  •  
Rule 12.5The sizeof operator shall not have an operand which is a function parameter declared as "array of type"
  •  
Rule 13.1Initializer lists shall not contain persistent side effects
  •  
Rule 13.2The value of an expression and its persistent side effects shall be the same under all permitted evaluation orders
  •  
Rule 13.3A full expression containing an increment (++) or decrement (--) operator should have no other potential side effects other than that caused by the increment or decrement operator
  •  
Rule 13.4The result of an assignment operator should not be used
  •  
Rule 13.5The right hand operand of a logical && or || operator shall not contain persistent side effects
  •  
Rule 13.6The operand of the sizeof operator shall not contain any expression which has potential side effects
  •  
Rule 14.1A loop counter shall not have essentially floating type
  •  
Rule 14.2A for loop shall be well-formed
  •  
Rule 14.3Controlling expressions shall not be invariant
  •  
Rule 14.4The controlling expression of an if statement and the controlling expression of an iteration-statement shall have essentially Boolean type
  •  
Rule 15.1The goto statement should not be used
  •  
Rule 15.2The goto statement shall jump to a label declared later in the same function
  •  
Rule 15.3Any label referenced by a goto statement shall be declared in the same block, or in any block enclosing the goto statement
  •  
Rule 15.4There shall be no more than one break or goto statement used to terminate any iteration statement
  •  
Rule 15.5A function should have a single point of exit at the end
  •  
Rule 15.6The body of an iteration-statement or a selection-statement shall be a compound-statement
  •  
Rule 15.7All if ... else if constructs shall be terminated with an else statement
  •  
Rule 16.2A switch label shall only be used when the most closely-enclosing compound statement is the body of a switch statement
  •  
Rule 16.3An unconditional break statement shall terminate every switch-clause
  •  
Rule 16.4Every switch statement shall have a default label
  •  
Rule 16.5A default label shall appear as either the first or the last switch label of a switch statement
  •  
Rule 16.6Every switch statement shall have at least two switch-clauses
  •  
Rule 16.7A switch-expression shall not have essentially Boolean type
  •  
Rule 17.1The features of <stdarg.h> shall not be used
  •  
Rule 17.2Functions shall not call themselves, either directly or indirectly
  •  
Rule 17.3A function shall not be declared implicitly
  •  
Rule 17.4All exit paths from a function with non-void return type shall have an explicit return statement with an expression
  •  
Rule 17.5The function argument corresponding to a parameter declared to have an array type shall have an appropriate number of elements
  •  
Rule 17.6The declaration of an array parameter shall not contain the static keyword between the []
  •  
Rule 17.7The value returned by a function having non-void return type shall be used
  •  
Rule 17.8A function parameter should not be modified
  •  
Rule 18.1A pointer resulting from arithmetic on a pointer operand shall address an element of the same array as that pointer operand
  •  
Rule 18.2Subtraction between pointers shall only be applied to pointers that address elements of the same array
  •  
Rule 18.3The relational operators >, >=, < and <= shall not be applied to objects of pointer type except where they point into the same object
  •  
Rule 18.4The +, -, += and -= operators should not be applied to an expression of pointer type
  •  
Rule 18.5Declarations should contain no more than two levels of pointer nesting
  •  
Rule 18.6The address of an object with automatic storage shall not be copied to another object that persists after the first object has ceased to exist
  •  
Rule 18.7Flexible array members shall not be declared
  •  
Rule 18.8Variable-length array types shall not be used
  •  
Rule 19.1An object shall not be assigned or copied to an overlapping object
  •  
Rule 19.2The union keyword should not be used
  •  
Rule 20.1#include directives should only be preceded by preprocessor directives or comments
  •  
Rule 20.2The ', " or \ characters and the /* or // character sequences shall not occur in a header file name
  •  
Rule 20.3The #include directive shall be followed by either a <filename> or "filename" sequence
  •  
Rule 20.4A macro shall not be defined with the same name as a keyword
  •  
Rule 20.5#undef should not be used
  •  
Rule 20.6Tokens that look like a preprocessing directive shall not occur within a macro argument
  •  
Rule 20.7Expressions resulting from the expansion of macro parameters shall be enclosed in parentheses
  •  
Rule 20.8The controlling expression of a #if or #elif preprocessing directive shall evaluate to 0 or 1
  •  
Rule 20.9All identifiers used in the controlling expression of #if or #elif preprocessing directives shall be #define'd before evaluation
  •  
Rule 20.10The # and ## preprocessor operators should not be used
  •  
Rule 20.11A macro parameter immediately following a # operator shall not immediately be followed by a ## operator
  •  
Rule 20.12A macro parameter used as an operand to the # or ## operators, which is itself subject to further macro replacement, shall only be used as an operand to these operators
  •  
Rule 20.13A line whose first token is # shall be a valid preprocessing directive
  •  
Rule 20.14All #else, #elif and #endif preprocessor directives shall reside in the same file as the #if, #ifdef or #ifndef directive to which they are related
  •  
Rule 21.1#define and #undef shall not be used on a reserved identifier or reserved macro name
  •  
Rule 21.2A reserved identifier or reserved macro name shall not be declared
  •  
Rule 21.3The memory allocation and deallocation functions of <stdlib.h> shall not be used
  •  
Rule 21.4The standard header file <setjmp.h> shall not be used
  •  
Rule 21.5The standard header file <signal.h> shall not be used
  •  
Rule 21.6The standard library input/output functions shall not be used
  •  
Rule 21.7The standard library functions atof, atoi, atol and atoll of <stdlib.h> shall not be used
  •  
Rule 21.8The standard library functions abort, exit and system of <stdlib.h> shall not be used
  •  
Rule 21.9The standard library functions bsearch and qsort of <stdlib.h> shall not be used
  •  
Rule 21.10The standard library time and date functions shall not be used
  •  
Rule 21.11The standard header file <tgmath.h> shall not be used
  •  
Rule 21.12The exception handling features of <fenv.h> should not be used
  •  
Rule 21.13Any value passed to a function in <ctype.h> shall be representable as an unsigned char or be the value EOF
  •  
Rule 21.14The standard library function memcmp shall not be used to compare null terminated strings
  •  
Rule 21.15The pointer arguments to the standard library functions memcpy, memmove and memcmp shall be pointers to qualified or unqualified versions of compatible types
  •  
Rule 21.16The pointer arguments to the standard library function memcmp shall point to either a pointer type, an essentially signed type, an essentially unsigned type, an essentially Boolean type or an essentially enum type
  •  
Rule 21.17Use of the string handling functions from <string.h> shall not result in accesses beyond the bounds of the objects referenced by their pointer parameters
  •  
Rule 21.18The size_t argument passed to any function in <string.h> shall have an appropriate value
  •  
Rule 21.19The pointers returned by the standard library functions localeconv, getenv, setlocale or strerror shall only be used as if they have pointer to const-qualified type
  •  
Rule 21.20The pointer returned by the standard library functions asctime, ctime, gmtime, localtime, localeconv, getenv, setlocale or strerror shall not be used following a subsequent call to the same function
  •  
Rule 22.1All resources obtained dynamically by means of standard library functions shall be explicitly released
  •  
Rule 22.2A block of memory shall only be freed if it was allocated by means of a standard library function
  •  
Rule 22.3The same file shall not be open for read and write access at the same time on different streams
  •  
Rule 22.4There shall be no attempt to write to a stream which has been opened as read-only
  •  
Rule 22.5A pointer to a FILE object shall not be dereferenced
  •  
Rule 22.6The value of a pointer to a FILE shall not be used after the associated stream has been closed
  •  
Rule 22.7The macro EOF shall only be compared with the unmodified return value from any standard library function capable of returning EOF
  •  
Rule 22.8The value of errno shall be set to zero prior to a call to an errno-setting-function
  •  
Rule 22.9The value of errno shall be tested against zero after calling an errno-setting-function
  •  
Rule 22.10The value of errno shall only be tested when the last function to be called was an errno-setting-function
  •  

MISRA C++ 2008 (43 / 211)

NumberDescriptionDone
Rule 0-1-1A project shall not contain unreachable code
  •  
Rule 0-1-2A project shall not contain infeasible paths
  •  
Rule 0-1-3A project shall not contain unused variables
  •  
Rule 0-1-4A project shall not contain non-volatile POD variables having only one use
  •  
Rule 0-1-5A project shall not contain unused type declarations
  •  
Rule 0-1-6A project shall not contain instances of non-volatile variables being given values that are never subsequently used
  •  
Rule 0-1-7The value returned by a function having non-void return type that is not an overloaded operator shall always be used
  •  
Rule 0-1-8All functions with void return type shall have external side effect(s)
  •  
Rule 0-1-9There shall be no dead code
  •  
Rule 0-1-10Every defined function shall be called at least once
  •  
Rule 0-1-11There shall be no unused parameters (named or unnamed) in non-virtual functions
  •  
Rule 0-1-12There shall be no unused parameters (named or unnamed) in the set of parameters for a virtual function and all the functions that override it
  •  
Rule 0-2-1An object shall not be assigned to an overlapping object
  •  
Rule 0-3-2If a function generates error information, then that error information shall be tested
  •  
Rule 2-3-1Trigraphs shall not be used
  •  
Rule 2-5-1Digraphs shall not be used
  •  
Rule 2-7-1The character sequence /* shall not be used within a C-style comment
  •  
Rule 2-7-2Sections of code shall not be "commented out" using C-style comments
  •  
Rule 2-7-3Sections of code should not be "commented out" using C++ comments
  •  
Rule 2-10-1Different identifiers shall be typographically unambiguous
  •  
Rule 2-10-2Identifiers declared in an inner scope shall not hide an identifier declared in an outer scope
  •  
Rule 2-10-3A typedef name (including qualification, if any) shall be a unique identifier
  •  
Rule 2-10-4A class, union or enum name (including qualification, if any) shall be a unique identifier
  •  
Rule 2-10-5The identifier name of a non-member object or function with static storage duration should not be reused
  •  
Rule 2-10-6If an identifier referes to a type, it shall not also refer to an object or a function in the same scope
  •  
Rule 2-13-1Only those escape sequences that are defined in ISO/IEC 14882
  •  
Rule 2-13-2Octal constants (other than zero) and octal escape sequences (other than "\0") shall not be used
  •  
Rule 2-13-3A "U" suffix shall be applied to all octal or hexadecimal integer literals of unsigned type
  •  
Rule 2-13-4Literal suffixes shall be upper case
  •  
Rule 2-13-5Narrow and wide string literals shall not be concatenated
  •  
Rule 3-1-1It shall be possible to include any header file in multiple translation units without violating the One Definition Rule
  •  
Rule 3-1-2Functions shall not be declared at block scope
  •  
Rule 3-1-3When an array is declared, its size shall either be stated explicitly or defined implicitly by initialization
  •  
Rule 3-2-1All declarations of an object or function shall have compatible types
  •  
Rule 3-2-2The One Definition Rule shall not be violated
  •  
Rule 3-2-3A type, object or function that is used in multiple translation units shall be declared in one and only one file
  •  
Rule 3-2-4An identifier with external linkage shall have exactly one definition
  •  
Rule 3-3-1Objects or functions with external linkage shall be declared in a header file
  •  
Rule 3-3-2If a function has internal linkage then all re-declarations shall include the static storage class specifier
  •  
Rule 3-4-1An identifier declared to be an object or type shall be defined in a block that minimizes its visibility
  •  
Rule 3-9-1The types used for an object, a function return type, or a function parameter shall be token-for-token identical in all declarations and re-declarations
  •  
Rule 3-9-2typedefs that indicate size and signedness should be used in place of the basic numerical types
  •  
Rule 3-9-3The underlying bit representation of floating-point values shall not be used
  •  
Rule 4-5-1Expressions with type bool shall not be used as operands to built-in operators other than the assignment operator =, the logical operators &&, ||, !, the equality operators == and !=, the unary & operator, and the conditional operator
  •  
Rule 4-5-2Expressions with type enum shall not be used as operands to built-in operators other than the subscript operator [ ], the assignment operator =, the equality operators == and !=, the unary & operator, and the relational operators <, <=, >, >=
  •  
Rule 4-5-3Expressions with type (plain) char and wchar_t shall not be used as operands to built-in operators other than the assignment operator =, the equality operators == and !=, and the unary & operator
  •  
Rule 4-10-1NULL shall not be used as an integer value
  •  
Rule 4-10-2Literal zero (0) shall not be used as the null-pointer-constant
  •  
Rule 5-0-1The value of an expression shall be the same under any order of evaluation that the standard permits
  •  
Rule 5-0-3A cvalue expression shall not be implicitly converted to a different underlying type
  •  
Rule 5-0-4An implicit integral conversion shall not change the signedness of the underlying type
  •  
Rule 5-0-5There shall be no implicit floating-integral conversions
  •  
Rule 5-0-6An implicit integral or floating-point conversion shall not reduce the size of the underlying type
  •  
Rule 5-0-7There shall be no explicit floating-integral conversions of a cvalue expression
  •  
Rule 5-0-8An explicit integral or floating-point conversion shall not increase the size of the underlying type of a cvalue expression
  •  
Rule 5-0-9An explicit integral conversion shall not change the signedness of the underlying type of a cvalue expression
  •  
Rule 5-0-10If the bitwise operators ~ and << are applied to an operand with an underlying type of unsigned char or unsigned short, the result shall be immediately cast to the underlying type of the operand
  •  
Rule 5-0-11The plain char type shall only be used for the storage and use of character values
  •  
Rule 5-0-12signed char and unsigned char type shall only be used for the storage and use of numeric values
  •  
Rule 5-0-13The condition of an if-statement and the condition of an iteration-statement shall have type bool
  •  
Rule 5-0-14The first operand of a conditional-operator shall have type bool
  •  
Rule 5-0-15Array indexing shall be the only form of pointer arithmetic
  •  
Rule 5-0-16A pointer operand and any pointer resulting from pointer arithmetic using that operand shall both address elements of the same array
  •  
Rule 5-0-17Subtraction between pointers shall only be applied to pointers that address elements of the same array
  •  
Rule 5-0-18>, >=, <, <= shall not be applied to objects of pointer type, except where they point to the same array
  •  
Rule 5-0-19The declaration of objects shall contain no more than two levels of pointer indirection
  •  
Rule 5-0-20Non-constant operands to a binary bitwise operator shall have the same underlying type
  •  
Rule 5-0-21Bitwise operators shall only be applied to operands of unsigned underlying type
  •  
Rule 5-2-1Each operand of a logical && or || shall be a postfix-expression
  •  
Rule 5-2-2A pointer to a virtual base class shall only be cast to a pointer to a derived class by means of dynamic_cast
  •  
Rule 5-2-3Casts from a base class to a derived class should not be performed on polymorphic types
  •  
Rule 5-2-4C-style casts (other than void casts) and functional notation casts (other than explicit constructor calls) shall not be used
  •  
Rule 5-2-5A cast shall not remove any const or volatile qualification from the type of a pointer or reference
  •  
Rule 5-2-6A cast shall not convert a pointer to a function to any other pointer type, including a pointer to function type
  •  
Rule 5-2-7An object with pointer type shall not be converted to an unrelated pointer type, either directly or indirectly
  •  
Rule 5-2-8An object with integer type or pointer to void type shall not be converted to an object with pointer type
  •  
Rule 5-2-9A cast should not convert a pointer type to an integral type
  •  
Rule 5-2-10The increment (++) and decrement (--) operators should not be mixed with other operators in an expression
  •  
Rule 5-2-11The comma operator, && operator and the || operator shall not be overloaded
  •  
Rule 5-2-12An identifier with array type passed as a function argument shall not decay to a pointer
  •  
Rule 5-3-1Each operand of the ! operator, the logical && or the logical || operators shall have type bool
  •  
Rule 5-3-2The unary minus operator shall not be applied to an expression whose underlying type is unsigned
  •  
Rule 5-3-3The unary & operator shall not be overloaded
  •  
Rule 5-3-4Evaluation of the operand to the sizeof operator shall not contain side effects
  •  
Rule 5-8-1The right hand operand of a shift operator shall lie between zero and one less than the width in bits of the underlying type of the left hand operand
  •  
Rule 5-14-1The right hand operand of a logical && or || operator shall not contain side effects
  •  
Rule 5-18-1The comma operator shall not be used
  •  
Rule 5-19-1Evaluation of constant unsigned integer expressions should not lead to wrap-around
  •  
Rule 6-2-1Assignment operators shall not be used in sub-expressions
  •  
Rule 6-2-2Floating-point expressions shall not be directly or indirectly tested for equality or inequality
  •  
Rule 6-2-3Before preprocessing, a null statement shall only occur on a line by itself; it may be followed by a comment, provided that the first character following the null statement is a white‐space character
  •  
Rule 6-3-1The statement forming the body of a switch, while, do ... while or for statement shall be a compound statement
  •  
Rule 6-4-1An if ( condition ) construct shall be followed by a compound statement. The else keyword shall be followed by either a compound statement, or another if statement
  •  
Rule 6-4-2All if ... else if constructs shall be terminated with an else clause
  •  
Rule 6-4-4A switch-label shall only be used when the most closely- enclosing compound statement is the body of a switch statement
  •  
Rule 6-4-5An unconditional throw or break statement shall terminate every non‐empty switch-clause
  •  
Rule 6-4-6The final clause of a switch statement shall be the default-clause
  •  
Rule 6-4-7The condition of a switch statement shall not have bool type
  •  
Rule 6-4-8Every switch statement shall have at least one case-clause
  •  
Rule 6-5-1A for loop shall contain a single loop-counter which shall not have floating type
  •  
Rule 6-5-2If loop-counter is not modified by -- or ++, then, within condition, the loop-counter shall only be used as an operand to <=, <, > or >=
  •  
Rule 6-5-3The loop-counter shall not be modified within condition or statement
  •  
Rule 6-5-4The loop-counter shall be modified by one of
  •  
Rule 6-5-5A loop-control-variable other than the loop-counter shall not be modified within condition or expression
  •  
Rule 6-5-6A loop-control-variable other than the loop-counter which is modified in statement shall have type bool
  •  
Rule 6-6-1Any label referenced by a goto statement shall be declared in the same block, or in a block enclosing the goto statement
  •  
Rule 6-6-2The goto statement shall jump to a label declared later in the same function body
  •  
Rule 6-6-3The continue statement shall only be used within a well- formed for loop
  •  
Rule 6-6-4For any iteration statement there shall be no more than one break or goto statement used for loop termination
  •  
Rule 6-6-5A function shall have a single point of exit at the end of the function
  •  
Rule 7-1-1A variable which is not modified shall be const qualified
  •  
Rule 7-1-2A pointer or reference parameter in a function shall be declared as pointer to const or reference to const if the corresponding object is not modified
  •  
Rule 7-2-1An expression with enum underlying type shall only have values corresponding to the enumerators of the enumeration
  •  
Rule 7-3-1The global namespace shall only contain main, namespace declarations and extern "C" declarations
  •  
Rule 7-3-2The identifier main shall not be used for a function other than the global function main
  •  
Rule 7-3-3There shall be no unnamed namespaces in header files
  •  
Rule 7-3-4using-directives shall not be used
  •  
Rule 7-3-5Multiple declarations for an identifier in the same namespace shall not straddle a using-declaration for that identifier
  •  
Rule 7-3-6using-directives and using-declarations (excluding class scope or function scope using-declarations) shall not be used in header files
  •  
Rule 7-4-2Assembler instructions shall only be introduced using the asm declaration
  •  
Rule 7-4-3Assembly language shall be encapsulated and isolated
  •  
Rule 7-5-1A function shall not return a reference or a pointer to an automatic variable (including parameters), defined within the function
  •  
Rule 7-5-2The address of an object with automatic storage shall not be assigned to another object that may persist after the first object has ceased to exist
  •  
Rule 7-5-3A function shall not return a reference or a pointer to a parameter that is passed by reference or const reference
  •  
Rule 7-5-4Functions should not call themselves, either directly or indirectly
  •  
Rule 8-0-1An init-declarator-list or a member-declarator-list shall consist of a single init-declarator or member-declarator respectively
  •  
Rule 8-3-1Parameters in an overriding virtual function shall either use the same default arguments as the function they override, or else shall not specify any default arguments
  •  
Rule 8-4-1Functions shall not be defined using the ellipsis notation
  •  
Rule 8-4-2The identifiers used for the parameters in a re- declaration of a function shall be identical to those in the declaration
  •  
Rule 8-4-3All exit paths from a function with non-void return type shall have an explicit return statement with an expression
  •  
Rule 8-4-4A function identifier shall either be used to call the function or it shall be preceded by &
  •  
Rule 8-5-1All variables shall have a defined value before they are used
  •  
Rule 8-5-2Braces shall be used to indicate and match the structure in the non-zero initialization of arrays and structures
  •  
Rule 8-5-3In an enumerator list, the = construct shall not be used to explicitly initialize members other than the first, unless all items are explicitly initialized
  •  
Rule 9-3-1const member functions shall not return non-const pointers or references to class-data
  •  
Rule 9-3-2Member functions shall not return non-const handles to class-data
  •  
Rule 9-3-3If a member function can be made static then it shall be made static, otherwise if it can be made const then it shall be made const
  •  
Rule 9-5-1Unions shall not be used
  •  
Rule 9-6-2Bit-fields shall be either bool type or an explicitly unsigned or signed integral type
  •  
Rule 9-6-4Named bit-fields with signed integer type shall have a length of more than one bit
  •  
Rule 10-1-1Classes should not be derived from virtual bases
  •  
Rule 10-1-2A base class shall only be declared virtual if it is used in a diamond hierarchy
  •  
Rule 10-1-3An accessible base class shall not be both virtual and non-virtual in the same hierarchy
  •  
Rule 10-2-1All accessible entity names within a multiple inheritance hierarchy should be unique
  •  
Rule 10-3-1There shall be no more than one definition of each virtual function on each path through the inheritance hierarchy
  •  
Rule 10-3-2Each overriding virtual function shall be declared with the virtual keyword
  •  
Rule 10-3-3A virtual function shall only be overridden by a pure virtual function if it is itself declared as pure virtual
  •  
Rule 11-0-1Member data in non-POD class types shall be private
  •  
Rule 12-1-1An object’s dynamic type shall not be used from the body of its constructor or destructor
  •  
Rule 12-1-2All constructors of a class should explicitly call a constructor for all of its immediate base classes and all virtual base classes
  •  
Rule 12-1-3All constructors that are callable with a single argument of fundamental type shall be declared explicit
  •  
Rule 12-8-1A copy constructor shall only initialize its base classes and the non-static members of the class of which it is a member
  •  
Rule 12-8-2The copy assignment operator shall be declared protected or private in an abstract class
  •  
Rule 14-5-1A non-member generic function shall only be declared in a namespace that is not an associated namespace
  •  
Rule 14-5-2A copy constructor shall be declared when there is a template constructor with a single parameter that is a generic parameter
  •  
Rule 14-5-3A copy assignment operator shall be declared when there is a template assignment operator with a parameter that is a generic parameter
  •  
Rule 14-6-1In a class template with a dependent base, any name that may be found in that dependent base shall be referred to using a qualified-id or this->
  •  
Rule 14-6-2The function chosen by overload resolution shall resolve to a function declared previously in the translation unit
  •  
Rule 14-7-1All class templates, function templates, class template member functions and class template static members shall be instantiated at least once
  •  
Rule 14-7-2For any given template specialization, an explicit instantiation of the template with the template- arguments used in the specialization shall not render the program ill-formed
  •  
Rule 14-7-3All partial and explicit specializations for a template shall be declared in the same file as the declaration of their primary template
  •  
Rule 14-8-1Overloaded function templates shall not be explicitly specialized
  •  
Rule 14-8-2The viable function set for a function call should either contain no function specializations, or only contain function specializations
  •  
Rule 15-0-2An exception object should not have pointer type
  •  
Rule 15-0-3Control shall not be transferred into a try or catch block using a goto or a switch statement
  •  
Rule 15-1-1The assignment-expression of a throw statement shall not itself cause an exception to be thrown
  •  
Rule 15-1-2NULL shall not be thrown explicitly
  •  
Rule 15-1-3An empty throw (throw;) shall only be used in the compound-statement of a catch handler
  •  
Rule 15-3-1Exceptions shall be raised only after start-up and before termination of the program
  •  
Rule 15-3-2There should be at least one exception handler to catch all otherwise unhandled exceptions
  •  
Rule 15-3-3Handlers of a function-try-block implementation of a class constructor or destructor shall not reference non- static members from this class or its bases
  •  
Rule 15-3-4Each exception explicitly thrown in the code shall have a handler of a compatible type in all call paths that could lead to that point
  •  
Rule 15-3-5A class type exception shall always be caught by reference
  •  
Rule 15-3-6Where multiple handlers are provided in a single try-catch statement or function-try-block for a derived class and some or all of its bases, the handlers shall be ordered most-derived to base class
  •  
Rule 15-3-7Where multiple handlers are provided in a single try-catch statement or function-try-block, any ellipsis (catch-all) handler shall occur last
  •  
Rule 15-4-1If a function is declared with an exception-specification, then all declarations of the same function (in other translation units) shall be declared with the same set of type-ids
  •  
Rule 15-5-1A class destructor shall not exit with an exception
  •  
Rule 15-5-2Where a function’s declaration includes an exception- specification, the function shall only be capable of throwing exceptions of the indicated type(s)
  •  
Rule 15-5-3The terminate() function shall not be called implicitly
  •  
Rule 16-0-1#include directives in a file shall only be preceded by other preprocessor directives or comments
  •  
Rule 16-0-2Macros shall only be #define’d or #undef’d in the global namespace
  •  
Rule 16-0-3#undef shall not be used
  •  
Rule 16-0-4Function-like macros shall not be defined
  •  
Rule 16-0-5Arguments to a function-like macro shall not contain tokens that look like preprocessing directives
  •  
Rule 16-0-6In the definition of a function-like macro, each instance of a parameter shall be enclosed in parentheses, unless it is used as the operand of # or ##
  •  
Rule 16-0-7Undefined macro identifiers shall not be used in #if or #elif preprocessor directives, except as operands to the defined operator
  •  
Rule 16-0-8If the # token appears as the first token on a line, then it shall be immediately followed by a preprocessing token
  •  
Rule 16-1-1The defined preprocessor operator shall only be used in one of the two standard forms
  •  
Rule 16-1-2All #else, #elif and #endif preprocessor directives shall reside in the same file as the #if or #ifdef directive to which they are related
  •  
Rule 16-2-1The pre-processor shall only be used for file inclusion and include guards
  •  
Rule 16-2-2C++ macros shall only be used for include guards, type qualifiers, or storage class specifiers
  •  
Rule 16-2-3Include guards shall be provided
  •  
Rule 16-2-4The ', ", /* or // characters shall not occur in a header file name
  •  
Rule 16-2-5The \ character should not occur in a header file name
  •  
Rule 16-2-6The #include directive shall be followed by either a <filename> or "filename" sequence
  •  
Rule 16-3-1There shall be at most one occurrence of the # or ## operators in a single macro definition
  •  
Rule 16-3-2The # and ## operators should not be used
  •  
Rule 17-0-1Reserved identifiers, macros and functions in the standard library shall not be defined, redefined or undefined
  •  
Rule 17-0-2The names of standard library macros and objects shall not be reused
  •  
Rule 17-0-3The names of standard library functions shall not be overridden
  •  
Rule 17-0-5The setjmp macro and the longjmp function shall not be used
  •  
Rule 18-0-1The C library shall not be used
  •  
Rule 18-0-2The library functions atof, atoi and atol from library <cstdlib> shall not be used
  •  
Rule 18-0-3The library functions abort, exit, getenv and system from library <cstdlib> shall not be used
  •  
Rule 18-0-4The time handling functions of library <ctime> shall not be used
  •  
Rule 18-0-5The unbounded functions of library <cstring> shall not be used
  •  
Rule 18-2-1The macro offsetof shall not be used
  •  
Rule 18-4-1Dynamic heap memory allocation shall not be used
  •  
Rule 18-7-1The signal handling facilities of <csignal> shall not be used
  •  
Rule 19-3-1The error indicator errno shall not be used
  •  
Rule 27-0-1The stream input/output library <cstdio> shall not be used
  •  
  • No labels