Code review rules

Code Review for C

The code review tool covers rules from the lists the rules that produced and error or a warning. Each rule can be individually disabled or assigned a Warning or Error severity by using the Rule configuration window. Some rules also have parameters that can be changed.

Among other guidelines, the code review tool implements most rules from the MISRA-C:2004 standard, "Guidelines for the use of the C language in critical systems". These rules are referenced with an M prefix.

In addition to the industry standard rules, OneTest Embedded provides some additional coding guidelines, which are referenced with an E prefix.

 

Code review reference

MISRA-C: 2004 reference

Code review message

Code compliance

M1.1

Rule 1.1

ANSI C error: <error>

M1.1w

Rule 1.1

ANSI C warning: <warning>

Language extensions

M2.1

Rule 2.1

 

Assembly language has not been isolated into a macro or function.

M2.2

Rule 2.2

Comments should only use the style /*...*/.

M2.3

Rule 2.3

The character sequence /* should not be used within a comment.

Documentation

M3.4

Rule 3.4

Use of #pragma <name> should always be encapsulated and documented.

Character sets

M4.1

Rule 4.1

Only ISO C escape sequences should be allowed.

M4.2

Rule 4.2

Trigraphs '??x' should not be used.

Identifiers

M5.1.1

Rule 5.1

Identifiers <name> and <name> are identical in the first <value> characters.
Note  
 The number of characters can be specified.

M5.1.2

Rule 5.1

Identifiers <name> and <name> are ambiguous because of possible character confusion.

E5.1.3

-

Possible typing mistake between the variables <name> or <name> because of repeating character.

M5.2

Rule 5.2

Identifier <name> in an inner scope hides the same identifier in an outer scope : <location>.

M5.3

Rule 5.3

The typedef name <name> should not be reused. Name already found in <location>.

M5.4

Rule 5.4

A struct and union cannot use the same tag name

M5.5

Rule 5.5

The static object or function <name> should not be reused. Static object or function already found in <location>.

M5.7

Rule 5.7

The identifier <name> should not be reused. Identifier already found in <location>.

Types

M6.3

Rule 6.3

The C language numeric type <name> should not be used directly but instead used to define typedef.

E6.3

 

The implicit 'int' type should not be used.

M6.4

Rule 6.4

Bit fields should only be of type 'unsigned int' or 'signed int'.

M6.5

Rule 6.5

Bit fields of type 'signed int' must be at least 2 bits long.

Constants

M7.1

Rule 7.1

Octal constants and escape sequences should not be used.

Declarations and definitions

M8.1.1

Rule 8.1

A prototype for the function <name> should be declared before defining the function.

M8.1.2

Rule 8.1

A prototype for the function <name> should be declared before calling the function.

M8.2

Rule 8.2

The type of <name> should be explicitly stated.

M8.3

Rule 8.3

Parameters and return types should use the same type names in the declaration and in the definition, even if basic types are the same.

M8.4

Rule 8.4

If objects or functions are declared multiple times their types should be compatible.

E8.50

-

Use the const qualification for variable <name> which is pointer and which is not used to change the pointed object.

M8.5.1

Rule 8.5

The body of function <name> should not be located in a header file.

M8.5.2

Rule 8.5

The memory storage (definition) for the variable <name> should not be in a header file.

M8.6

Rule 8.6

Functions should not be declared at block scope.

M8.8.1

Rule 8.8

Declaration of <name> can not be found.

M8.8.2

Rule 8.8

Function <name> should only be declared in a single file. Redundant declaration found at: <position>.

M8.8.3

Rule 8.8

Object <name> should only be declared in a single file. Redundant declaration found at: <position>.

M8.9

Rule 8.9

The global object or function <name> should have exactly one external definition. Redundant definition found in <location>.

M8.11

Rule 8.11

Global objects or functions that are only used within the same file should be declared with using the static storage-class specifier.

M8.12

Rule 8.12

When a global array variable can be used from multiple files, its size should be defined at initialization time.

Initialization

M9.1

Rule 9.1

Variables with automatic storage duration should be initialized before being used.

M9.2

Rule 9.2

Nested braces should be used to initialize nested multi-dimension arrays and nested structures.

M9.3

Rule 9.3

Either all members or only the first member of an enumerator list should be initialized.

E9.4

-

The global variable <name> is not initialized.

Arithmetic type conversions

M10.1

Rule 10.1

Implicit conversion of a complex integer expression to a smaller sized integer is not allowed.

M10.1.1

Rule 10.1

Implicit conversion of an integer expression to a different signedness is not allowed.

M10.2

Rule 10.2

Conversion of a complex floating expression is not allowed. Only constant expressions can be implicitly converted and only to a wider floating type of the same signedness.

M10.3

Rule 10.3

Type cast of complex integer expressions is only allowed into a narrower type of the same signedness.

M10.4

Rule 10.4

Type cast of complex floating expressions is only allowed into a narrower type of the same signedness.

M10.6

Rule 10.6

Definitions of unsigned type constants should use the 'U' suffix.

Pointer type conversions

M11.1

Rule 11.1

A function pointer should not be converted to another type of pointer.

M11.2

Rule 11.2

An object pointer should not be converted to another type of pointer.

M11.3

Rule 11.3

Casting a pointer type to an integer type should not occur.

M11.4.1

Rule 11.4

Casting an object pointer type to a different object pointer type should not occur.

M11.4.2

Rule 11.4

Casting an object pointer type to a different object pointer type should not occur, especially when object sizes are not the same.

M11.5

Rule 11.5

Casting of pointers to a type that removes any const or volatile qualification on the pointed object should not occur.

Expressions

M12.1

Rule 12.1

Implicit operator precedence may cause ambiguity. Use parenthesis to clarify this expression.

M12.3

Rule 12.3

The sizeof operator should not be used on expressions that contain side effects.

M12.4.1

Rule 12.4

An expression that contains a side effect should not be used in the right-hand operand of a logical  && or || operator.

M12.4.2

Rule 12.4

The function in the right-hand operand of a logical && or || operator might cause side effects.

M12.5

Rule 12.5

Parenthesis should be used around expressions that are operands of a logical  && or ||.

E12.51

-

Ternary expression ?: should not be used.

E12.52

-

The first operand of a ternary operator should be Boolean.

E12.53

-

The second and third operands of a ternary operator should have the same type.

E12.54

-

Expressions should not cause a side effect assignment.

M12.6.1

Rule 12.6

Only Boolean operands should be used with logical operators ( &&, || and !).

M12.6.2

Rule 12.6

The operator on a Boolean expression should be a logical operator ( &amp;&amp;, || or !).

M12.7

Rule 12.7

Bitwise operators should only use unsigned operands.

M12.8

Rule 12.8

The right-hand operand of a shift operator should not be too big or negative.

M12.9

Rule 12.9

Only use unary minus operators with signed expressions.

M12.10

Rule 12.10

Do not use the comma operator

M12.13

Rule 12.13

The increment (++) or the decrement (--) operators should not be used with other operators in an expression.

Control statement expressions

M13.1.1

Rule 13.1

Boolean expressions should not contain assignment operators.

M13.1.2

Rule 13.1

Boolean expressions should not contain side effect operators.

M13.3

Rule 13.3

The equal or not equal operator should not be used in floating-point expressions.

M13.7

Rule 13.7

Invariant Boolean expressions should not be used.

Control flow

M14.1

Rule 14.1

Unreachable code.

M14.2

Rule 14.2

A non-null statement should either have a side effect or change the control flow.

M14.3

Rule 14.3

A null statement in original source code should be on a separate line and the semicolon should be followed by at least one white space and then a comment.

M14.4

Rule 14.4

Do not use the goto statement.

M14.5

Rule 14.5

Do not use the continue statement.

M14.6

Rule 14.6

Only one break statement should be used within a loop.

M14.7.1

Rule 14.7

Only one exit point should be defined in a function.

M14.7.2

Rule 14.7

The return keyword should not be used in a conditional block.

M14.8.1

Rule 14.8

The switch statement should be followed by a compound statement {}.

M14.8.2

Rule 14.8

The while statement should be followed by a compound statement {}.

M14.8.3

Rule 14.8

The do..while statement should contain a compound statement {}.

M14.8.4

Rule 14.8

The for statement should be followed by a compound statement {}.

M14.9.1

Rule 14.9

The if (expression) construct should be followed by a compound statement {}.

M14.9.2.1

Rule 14.9

The else keyword should be followed by either a compound statement or another if statement.

M14.9.2.2

Rule 14.9

The else keyword should be followed by a compound statement

M14.10

Rule 14.10

All if ... else if sequences should have an else block.

Switch statements

M15.1

Rule 15.1

A case or default statements should only be used directly within the compound block of a switch statement.

E15.10

-

The switch expression should not have side effects.

M15.2

Rule 15.2

The break statement should only be used to terminate every non-empty switch block.

M15.3.1

Rule 15.3

The switch statement should have a default clause.

M15.3.2

Rule 15.3

The default clause should be the last clause of the switch statement.

M15.4.1

Rule 15.4

A Boolean should not be used as a switch expression.

M15.4.2

Rule 15.4

A constant should not be used as a switch expression.

M15.5

Rule 15.5

At least one case should be defined in the switch.

Functions

M16.1

Rule 16.1

The function <name> should not have a variable number of arguments.

M16.2.1

Rule 16.2

Recursive functions are not allowed. The function <name> is directly recursive.

M16.2.2

Rule 16.2

Recursive functions are not allowed. The function <name> is recursive when calling <name>.

M16.3

Rule 16.3

The function prototype should name all its parameters.

M16.4

Rule 16.4

The identifiers used in the prototype and definition should be the same.

M16.5

Rule 16.5

Functions with no parameters should use the void type.

E16.50

-

The function <name> is never referenced.

M16.6

Rule 16.6

The number of arguments used in the call does not match the number declared in the prototype.

M16.7

Rule 16.7

Use the const qualification for parameter <name> which is pointer and which is not used to change the pointed object.

M16.8

Rule 16.8

The return should always be defined with an expression for non-void functions.

M16.9

Rule 16.9

Function identifiers should always use a parenthesis or a preceding &.

M16.10

Rule 16.10

When a function returns a value, this value should be used.

Pointers and arrays

M17.4

Rule 17.4

Pointer arithmetic except array indexing should not be used.

M17.5

Rule 17.5

A declaration should not use more than two levels of pointer indirection.

Structures and unions

M18.1

Rule 18.1

Structure or union types should be finalized before the end of the compilation units.

M18.4

Rule 18.4

Do not use unions.

Preprocessing directives

M19.1

Rule 19.1

Only preprocessor directives or comments may occur before the #include statements.

M19.3

Rule 19.3

Filenames with the #include directive should always use the <filename> or "filename" syntax.

M19.4

Rule 19.4

A C macro should only be expanded to a constant, a braced initializer, a parenthesised expression, a storage class keyword, a type qualifier, or a do-while-zero block.

M19.5

Rule 19.5

Macro definitions or #undef should not be located within a block.

M19.6

Rule 19.6

Do not use the #undef directive.

M19.8

Rule 19.8

Missing argument when calling the macro.

M19.9

Rule 19.9

The preprocessing directive <name> should not be used as argument to the macro.

M19.10

Rule 19.10

The parameter <name> in the macro should be enclosed in parentheses except when it is used as the operand of # or ##.

M19.11

Rule 19.11

Undefined macro identifier in the preprocessor directive.

M19.12

Rule 19.12

The # or ## preprocessor operator should not be used more than once.

M19.13

Rule 19.13

The # and ## preprocessor operator should be avoided.

M19.14

Rule 19.14

Only use the 'defined' preprocessor operator with a single identifier.

M19.15

Rule 19.15

Header file contents should be protected against multiple inclusions

M19.16

Rule 19.16

Possible bad syntax in preprocessing directive.

M19.17

Rule 19.17

A #if, #ifdef, #else, #elif or #endif preprocessor directive has been found without its matching directive in the same file.

Standard libraries

M20.1

Rule 20.1

<name> should not be defined, redefined or undefined.

M20.5

Rule 20.5

The variable <name> should not be used.

Parameter: List of forbidden variables

M20.6

Rule 20.6

The macro <name> should not be used.
Parameter: List of forbidden macros

M20.4

Rules 20.4, 20.7, 20.10, and 20.11

The library function <name> should not be used.

Parameter: List of forbidden library functions

M20.8

Rules 20.8, 20.9, and 20.12

The header filename <name> should not be used.

Parameter: List of forbidden header filenames

 

 

Related Topics

Understanding code review reportsConfiguring code review rulesCode review overview