Rule 2.3 | The character sequence /* shall NOt be used within a comment. |
Rule 2.4 | Sections of code should NOt be “commented out”. |
Rule 4.2 | Trigraphs shall NOt be used. |
Rule 5.2 | Identifiers in an inner scope shall NOt use the same name as an identifier in an outer scope, and therefore hide that identifier. |
Rule 5.3 | A typedef name shall be a unique identifier. |
Rule 5.4 | A tag name shall be a unique identifier. |
Rule 5.7 | NO identifier name should be reused. |
Rule 6.4 | Bit fields shall only be defined to be of type unsigned int or signed int. |
Rule 6.5 | Bit fields of signed type shall be at least 2 bits long. |
Rule 7.1 | Octal constants (other than zero) and octal escape sequences shall NOt be used. |
Rule 8.2 | Whenever an object or function is declared or defined, its type shall be explicitly stated. |
Rule 8.7 | Objects shall be defined at block scope if they are only accessed from within a single function. |
Rule 8.8 | An external object or function shall be declared in one and only one file. |
Rule 8.9 | An identifier with external linkage shall have exactly one external definition. |
Rule 8.11 | The static storage class specifier shall be used in definitions and declarations of objects and functions that have internal linkage. |
Rule 8.12 | When an array is declared with external linkage, its size shall be state explicitly or defined implicitly by initialisation. |
Rule 9.1 | All automatic variables shall have been assigned a value before being used. |
Rule 9.2 | Braces shall be used to indicate and match the structure in the NOn-zero initialisation of arrays and structures. |
Rule 9.3 | In an enumerator list, the “=” construct shall NOt be used to explicitly initialise members other than the first, unless all items are explicitly initialised. |
Rule 10.1 | The value of an expression of integer type shall NOt be implicitly converted to a different underlying type if: (a) it is NOt a conversion to a wider integer type of the same signedness, or (b) signedness, or the
expression is complex, or (c) the expression is NOt constant and is a function argument, or (d) the expression is NOt constant and is a return expression. |
Rule 10.3 | The value of a complex expression of integer type shall only be cast to a type of the same signedness that is NO wider than the underlying type of the expression. |
Rule 10.4 | The value of a complex expression of floating type shall only be cast to a floating type that is narrower or of the same size. |
Rule 10.6 | A “U” suffix shall be applied to all constants of unsigned type. |
Rule 11.1 | Conversions shall NOt be performed between a pointer to a function and any type other than an integral type. |
Rule 11.2 | Conversions shall NOt be performed between a pointer to object and any type other than an integral type, aNOther pointer to object type or a pointer to void |
Rule 11.3 | A cast should NOt be performed between a pointer type and an integral type. |
Rule 11.4 | A cast should NOt be performed between a pointer to object type and a different pointer to object type. |
Rule 11.5 | A cast shall NOt be performed that removes any const or volatile qualification from the type addressed by a pointer. |
Rule 12.1 | Limited dependence should be placed on C’s operator precedence rules in expressions. |
Rule 12.2 | The value of an expression shall be the same under any order of evaluation that the standard permits. |
Rule 12.4 | The right-hand operand of a logical && or || operator shall NOt contain side effects. |
Rule 12.7 | Bitwise operators shall NOt be applied to operands whose underlying type is signed. |
Rule 12.10 | The comma operator shall NOt be used. |
Rule 12.11 | Evaluation of constant unsigned integer expressions should NOt lead to wrap-around. |
Rule 13.4 | The controlling expression of a for statement shall NOt contain any objects of floating type. |
Rule 14.1 | There shall be NO unreachable code. |
Rule 14.4 | The goto statement shall NOt be used. |
Rule 14.6 | For any iteration statement there shall be at most one break statement used for loop termination. |
Rule 14.7 | A function shall have a single point of exit at the end of the function. |
Rule 14.8 | The statement forming the body of a switch, while, do ... while or for statement shall be a compound statement. |
Rule 14.9 | An if (expression) construct shall be followed by a compound statement.
The else keyword shall be followed by either a compound statement, or aNOther if statement. |
Rule 14.10 | All if ... else if constructs shall be terminated with an else clause. |
Rule 15.0 | The MISRA C switch syntax shall be used |
Rule 15.1 | A switch label shall only be used when the most closely- enclosing compound statement is the body of a switch statement. |
Rule 15.2 | An unconditional break statement shall terminate every NOn- empty switch clause. |
Rule 15.3 | The final clause of a switch statement shall be the default clause. |
Rule 15.4 | A switch expression shall NOt represent a value that is effectively Boolean. |
Rule 15.5 | Every switch statement shall have at least one case clause. |
Rule 16.1 | Functions shall NOt be defined with a variable number of arguments. |
Rule 16.2 | Functions shall NOt call themselves, either directly or indirectly. |
Rule 16.3 | Identifiers shall be given for all of the parameters in a function prototype declaration. |
Rule 16.4 | The identifiers used in the declaration and definition of a function shall be identical. |
Rule 16.6 | The number of arguments passed to a function shall match the number of parameters. |
Rule 16.7 | A pointer parameter in a function prototype should be declared as pointer to const if the pointer is NOt used to modify the addressed object. |
Rule 16.8 | All exit paths from a function with NOn-void return type shall have an explicit return statement with an expression. |
Rule 17.2 | Pointer subtraction shall only be applied to pointers that address elements of the same array. |
Rule 17.3 |
, >=, <, <= shall NOt be applied to pointer types except where they point to the same array
|
Rule 18.2 | An object shall NOt be assigned to an overlapping object. |
Rule 18.4 | Unions shall NOt be used. |
Rule 19.1 | |
Rule 19.2 | NOn-standard characters should NOt occur in header file names in #include directives. |
Rule 19.3 | The #include directive shall be followed by either a or
″filename″ sequence. |
Rule 19.4 | C macros shall only expand to a braced initialiser, a constant, a string literal, a parenthesised expression, a type qualifier, a storage class specifier, or a do-while-zero construct. |
Rule 19.5 | Macros shall NOt be #define’d or #undef’d within a block. |
Rule 19.6 | |
Rule 19.7 | A function should be used in preference to a function-like macro. |
Rule 19.12 | There shall be at most one occurrence of the # or ## operators in a single macro definition. |
Rule 19.13 | The # and ## operators should NOt be used. |
Rule 19.17 | All #else, #elif and #endif preprocessor directives shall reside in the same file as the #if or #ifdef directive to which they are related. |
Rule 20.1 | Reserved identifiers, macros and functions in the standard library, shall NOt be defined, redefined or undefined. |
Rule 20.2 | The names of standard library macros, objects and functions shall NOt be reused. |
Rule 20.5 | The error indicator errNO shall NOt be used. |
Rule 20.7 | The setjmp macro and the longjmp function shall NOt be used. |
Rule 20.8 | The signal handling facilities of shall NOt be used |
Rule 20.9 | The input/output library shall NOt be used in production code. |
Rule 20.10 | The library functions atof, atoi and atol from library shall NOt be used. |
Rule 20.11 | The library functions abort, exit, getenv and system from library shall NOt be used. |
Rule 20.12 | The time handling functions of library shall NOt be used. |
