Misra C++ 2008

Misra C++ 2008 Standards

Introduction

MISRA, The Motor Industry Software Reliability Association, is a collaboration between vehicle manufacturers, component suppliers and engineering consultancies which seeks to promote best practice in developing safety-related electronic systems in road vehicles and other embedded systems.

To learn Misra C++ Standards, you can print this pdf

103 Queries in Misra C++ standards

9 Uncessary Constructs, 1 Storage, 8 Lexical Conventions, 7 Basic Concepts, 4 Standard Conversions, 17 Expressions, 15 Statements, 8 Declarations, 6 Declarators, 7 Classes, 5 Exceptions, 4 Preprocessor, 12 Library.

Uncessary Constructs

  • Rule 0–1–1: A project shall not contains unreachable code: Code is unreachable if there is no syntactic (controlflow) path to it. If such code exists, it is unclear if this is intentional or simply that an appropriate path has been accidentally omitted. Compilers may choose not to generate code for these constructs, meaning that, even if the unreachable code is intentional, it may not be present in the final executable code.

    This coding standard is computed with the following query:

    warnif count > 0         
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_unreachable" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}


  • Rule 0–1–2: A project shall not contain infeasible paths:

    This coding standard is computed with the following query:

    Infeasible paths occur where there is a syntactic path but the semantics ensure that the control flow path cannot be executed by any input data. One of the major problems here is the explosion of infeasible paths caused by: - if ... else statement sequences - Sequences of poorly chosen loop constructs Errors in conditions and poorly designed logic contribute to this problem. It is always possible to rewrite the code to eliminate these constructs. This process may then reveal faults.

    warnif count > 0         
    from issue in ImportedIssues where issue.ToolName=="CppCheck" && issue.Type=="knownConditionTrueFalse" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 0–1–3: A project shall not contains unused variables: Variables declared and never used in a project constitute noise and may indicate that the wrong variable name has been used somewhere. Removing these declarations reduces the possibility that they may later be used instead of the correct variable.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_unused_variable" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 0–1–4: A project shall not contain non-volatile POD variable having only one use: With the exception of volatile variables, variables declared and used only once do not contribute to program computations. A use is either an assignment (explicit initialization) or a reference. These variables are essentially noise but their presence may indicate that the wrong variable has been used elsewhere. Missing statements contribute to this problem.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="CppCheck" && issue.Type=="unreadVariable" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 0–1–5: A project shall not contains unused typedef declarations: If a type is declared but not used, then it is unclear to a reviewer if the type is redundant or it has been left unused by mistake.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_unused_local_typedef" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 0-1-7: The value returned by a function having a non-voidreturn type that is not an overloaded operator shall always be used: In C++ it is possible to call a function without using the return value, which may be an error. The return value of a function shall always be used.Overloaded operators are excluded, as they should behave in the same way as built-in operators.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Misra" && issue.Type=="Rule0-1-7" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 0-1-9: There shall be no dead code: Any executed statement whose removal would not affect program output constitutes dead code(also know as redundant code). It is unclear to a reviewer if this is intentional or has occurred due to an error.

    This coding standard is computed with the following query:

    warnif count > 0         
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_unreachable" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 0–1–11: There shall be no unused parameters in non virtual functions: Unused function parameters are often due to design changes and can lead to mismatched parameter lists.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues 
    where issue.ToolName=="Clang" && issue.Type=="warn_unused_parameter" 
    && issue.RelatedMethod!=null && issue.RelatedMethod.IsVirtual
    select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 0-1-12: There shall be no unused parameters (named or unnamed) in the set of parameters for a virtual function and all the functions that override it: Unused function parameters are often due to design changes and can lead to mismatched parameter lists.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues 
    where issue.ToolName=="Clang" && issue.Type=="warn_unused_parameter" 
    && issue.RelatedMethod!=null && !issue.RelatedMethod.IsVirtual
    select  new { issue,issue.FilePath,Line=issue.BeginLine}

Storage

  • Rule 0–2–1: An object shall not be assigned to an overlapping object: Assigning between objects that have an overlap in their physical storage leads to undefined behaviour.

    This coding standard is computed with the following query:

    warnif count > 0         
    from issue in ImportedIssues where issue.ToolName=="Clang-Tidy" && issue.Type=="cppcoreguidelines-pro-type-union-access" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

Lexical Conventions

  • Rule 2–3–1: Trigraphs shall not be used: Trigraphs are denoted by a sequence of 2 question marksfollowed by a specified third character(e.g. ??- represents a “~” (tilde) character and ??) represents a “]”). They can cause accidental confusion with other uses of two question marks.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="trigraph_ignored" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 2-5-1: Digraphs shall not be used: The use of digraphs may not meet developer expectations.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_cxx98_compat_less_colon_colon" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 2–7–1:The character sequence /* shall not be used within a C-style comment: C++ does not support the nesting of C-style comments even though some compilers support this as a non-portable language extension. A comment beginning with /*continuesuntilthefirst*/ is encountered. Any /* occurring inside a comment is a violation of this rule.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_nested_block_comment" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 2–10–2: Identifiers declared in a inner scope shall not hide an ientifier declared in out of dcope: If an identifier is declared in an inner scope and it uses the same name as an identifier that already exists in an outer scope, then the innermost declaration will “hide” the outer one. This may lead to developer confusion.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_decl_shadow" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 2-10-6: If an identifier refers to a type, it shall not also refer to an object or a function in the same scope: For C compatibility, it is possible in C++ for a name to refer to both a type and object or a type and function. This can lead to confusion.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="err_redefinition_different_kind" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 2–13–1: Only those escape sequences that are defined in ISO/IEC 14882:2003 shall be used: The use of an undefined escape sequence leads to undefined behaviour.
    The defined escape sequences(ISO/IEC14882:2003[1]§2.13.2)are:\n, \t, \v, \b, \r, \f, \a, \\, \?, \', \", \<Octal Number>, \x<Hexadecimal Number>

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="ext_unknown_escape" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 2–13–3: A U suffix shall be applied to all octal or hexadecimal integer literals of unsigned type: The type of an integer is dependent on a complex combination of factors including: The magnitude of the constant; The implemented sizes of the integer types; The presence of any suffixes; The number base in which the value is expressed (i.e. decimal, octal or hexadecimal).

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where  issue.Type=="Rule2-13-3" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 2–13–4: Literal suffixes shall be upper case: Using upper case literal suffixes removes the potential ambiguity between “1”(digit1) and “l” (letter el) for declaring literals.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where  issue.Type=="Rule2-13-4" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

Basic Concepts

  • Rule 3–1–1: It shall be possible to include any header file in multiple translationunits without violating the one definition rule: Header files should be used to declare objects, functions, inline functions, function templates, typedefs,macros,classes, and class templates and shall not contain or produce definitions of objects or functions (or fragment of functions or objects) that occupy storage.

    This coding standard is computed with the following query:

    warnif count > 0 
    from m in JustMyCode.Methods where m.NbLinesOfCode>0 
    && m.SourceDecls.First().SourceFile.FileNameExtension.StartsWith("h")
    select new { m,IncludeFile=m.SourceDecls.First().SourceFile.FilePathString }

  • Rule 3–1–2: Functions shall not be declared at block scope: A function declared at block scope will refer to a member of the enclosing namespace, and so the declaration should be explicitly placed at the namespace level. Additionally, where a declaration statement could either declare a function or an object, the compiler will choose to declare the function. To avoid potential developer confusion over the meaning of a declaration, functions should not be declared at block scope.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule3-1-2"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 3–1–3: When an array is declared, its size shall either be stated explicitly or defined implicitily by initialization: Although it is possible to declare an array of incomplete type and access its elements, it is safer to do so when the size of the array can be explicitly determined.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule3-1-3"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 3–3–1: Functions with extern linkage shall be declared in a header file: Placing the declarations of objects and functions with external linkage in a header file documents that they are intended to be accessible from other translation units. If external linkage is not required, then the object or function shall either be declared in an unnamed namespace or declared static. This will reduce the visibility of objects and functions, which is considered to be good practice.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule3-3-1"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 3–3–2: If a function has internal linkage then all re-declarations shall include the static storage class specifier: If the declaration of a function includes the static storage class specifier, then it has internal linkage.A re-declaration of such a function is not required to have the static keyword, but it will still have internal linkage. However, this is implicit and may not be obvious to a developer. It is therefore good practice to apply the static keyword consistently so that the linkage is explicitly stated.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule3-3-2"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 3–4–1: An identifier declared to be an object or type shall be defined in a block that minimizes its visibility: Defining variables in the minimum block scope possible reduces the visibility of those variables and therefore reduces the possibility that these identifiers will be used accidentally. Acorollaryof this is that global objects (including singleton function objects) shall be used in more than one function.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="CppCheck" && issue.Type=="variableScope"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 3–9–2: typedefs that indicate size and signedness should be used in place of the basic numerical types: The basic numerical types of char, int, short, long, float, double and long double should not be used,but specific-length typedefs should be used. This rule helps to clarify the size of the storage, but does not guarantee portability because of the asymmetric behaviour of integral promotion.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule3-9-2"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

Standard Conversions

Expressions

  • Rule 5–0–1:The value of an expression shall be the same under any order of evaluation that the standard permits: Apart from a few operators (notably &&, ||, ?: and , (comma)) the order in which sub-expressions are evaluated is unspecified and can vary. This means that no reliance can be placed on the order of evaluation of sub-expressions and, in particular, no reliance can be placed on the order in which side effects occur. Those points in the evaluation of an expression at which all previous side effects can be guaranteed to have taken place are called “sequence points”. Sequence points and side effects are described in Section 1.9(7) of ISO/IEC 14882:2003 [1].

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_unsequence_mod_use" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 5–0–4 : An implicit integral conversion shall not change the signedness of the underlying type: Some signed to unsigned conversions may lead to implementation-defined behaviour. This behaviour may not be consistent with developer expectations.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_impcast_integer_sign" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 5–0–5: There shall be no implicit floating-integral conversions: Conversions from floating point to integral types discard information,and may lead to undefined behaviour if the floating-point value cannot be represented in the integral type. Conversions from integral types to floating point types may not result in an exact representation,which may not be consistent with developer expectations.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_impcast_float_integer" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 5–0–6: An implicit integral or floating-point conversion shall not reduce the size of the underlying type: An implicit conversion that results in the size of a type being reduced may result in a loss of information.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_impcast_integer_precision" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 5-0-7: There shall be no explicit floating-integral conversions of a cvalue expression: A cast applied to the result of an expression does not change the type in which the expression is evaluated, which may be contrary to developer expectations.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang-Tidy" && issue.Type=="bugprone-integer-division" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 5–0–9: An explicit integral conversion shall not change the signedness of the underlying type of a cvalue expression: A signed to unsigned conversion may lead to an expression having a value inconsistent with developer expectations.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_impcast_integer_sign" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 5–0–15: Array indexing shall be the only form of pointer arithmetic: Array indexing is the only acceptable form of pointer arithmetic, because it is clearer and hence less error prone than pointer manipulation. This rule bans the explicit calculation of pointer values. Array indexing shall only be applied to objects defined as an array type. Any explicitly calculated pointer value has the potential to access unintended or invalid memory addresses. Pointers may go out of bounds of arrays or structures, or may even point to effectively arbitrary locations.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang-Tidy" && issue.Type=="cppcoreguidelines-pro-bounds-pointer-arithmetic" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 5–0–18: >, >=, <, <= shall not be applied to objects of pointer type, except where they point to the same array: Attempting to make comparisons between pointers will produce undefined behaviour if the two pointers do not point to the same object. Note: it is permissible to address the next element beyond the end of an array, but accessing this element is not allowed.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="CppCheck" && issue.Type=="comparePointers" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 5–2–2: A pointer to a virtual base class shall only be cast to a pointer to a derived class by means of dynamic_cast: Casting from a virtual base to a derived class, using any means other than dynamic_cast has undefined behaviour. The behaviour for dynamic_cast is defined.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="err_static_downcast_via_virtual" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 5–2–4: C-style casts(other than void casts) and functional notation casts (other than explicit constructor calls) shall not be used: C-style (cast notation), and functional notation casts that do not invoke a converting constructor are capable of performing casts between unrelated types.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_old_style_cast" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 5–2–6: A cast shall not convert a pointer to a function to any other pointer type, including a pointer to function type:

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_cxx98_compat_cast_fn_obj" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 5–3–3: The unary & operator shall not be overloaded: Taking the address of an object of incomplete type where the complete type contains a user declared operator & leads to undefined behaviour.

    This coding standard is computed with the following query:

    warnif count > 0 
    from m in JustMyCode.Methods where m.SimpleName== "operator&"
    select m

  • Rule 5–3–4: Evaluation of the operand to the sizeof operator shall not contain side effects: A possible programming error in C++ is to apply the sizeof operator to an expression and expect the expression to be evaluated. However, the expression is not evaluated as sizeof only acts on the type of the expression. To avoid this error, sizeof shall not be used on expressions that would contain side effects if they were used elsewhere, as the side effects will not occur.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_side_effects_unevaluated_context_sizeof" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 5–8–1: The 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: It is undefined behaviour if the right hand operand is negative, or greater than or equal to the width of the left hand operand. If, for example, the left hand operand of a left-shift or right-shift is a 16-bit integer, then it is important to ensure that this is shifted only by a number between 0 and 15 inclusive.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule5-8-1"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 5–14–1: The right hand operand of a logical && or || operator shall not contain side effects: There are some situations in C++ where certain parts of expressions may not be evaluated. If these sub-expressions contain side effects then those side effects may or may not occur, depending on the values of other sub expressions.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule5-14-1"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 5–18–1: The comma operator shall not be used: Use of the comma operator is generally detrimental to the readability of code, and the same effect can be achieved by other means.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule5-18-1"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 5-2-11: The comma operator, && operator and the || operator shall not be overloaded: Taking the address of an object of incomplete type where the complete type contains a user declared operator & leads to undefined behaviour.

    This coding standard is computed with the following query:

    warnif count > 0 
    from m in JustMyCode.Methods where m.SimpleName== "operator&"
    select m

Statements

  • Rule 6–2–1: Assignement operators shall not be used in sub-expressions: Assignments used in a sub-expression add an additional side effect to that of the full expression, potentially resulting in a value inconsistent with developer expectations. In addition, this helps to avoid getting = and == confused.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule6-2-1"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 6–2–2: Floating-point expressions shall not be directly or indirectly tested for equality or inequality: The inherent nature of floating-point types is such that comparisons of equality will often not evaluate to true, even when they are expected to. Also, the behaviour of such a comparison cannot be predicted before execution, and may well vary from one implementation to another.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_floatingpoint_eq" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 6–2–3: Before 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: Null statements should not normally be included deliberately, but where they are used, they shall appear on a line by themselves. White-space characters may precede the null statement to preserve indentation. If a comment follows the null statement, then at least one white-space character shall separate the null statement from the comment.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule6-2-3"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 6–3–1: The statement forming the body of a switch, while, do...while or for statement shall be a compound statement: If the bodies of these statements are not compound statements, then errors can occur if a developer fails to add the required braces when attempting to change a single statement body to a multi-statement body.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule6-3-1"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 6–4–1: An 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: If the bodies of these constructs are not compound statements, then errors can occur if a developer fails to add the required braces when attempting to change a single statement body to a multi-statement body.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule6-4-1"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 6–4–2: All if ... elseif constructs shall be terminated with an else clause: When an if statement is followed by one or more else if statements then the final else if shall be followed by an else statement. In the case of a simple if statement the else statement need not be included. The final else statement, which should either take appropriate action or contain a suitable comment as to why no action is taken, is defensive programming.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule6-4-2"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 6-4-3: A switch statement shall be a well-formed switch statement: A well-formed switch statement conforms to the following syntax rules, which are additional to the C++ standard syntax rules. All syntax rules not defined below areas defined in ISO/IEC14882:2003 [1].

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where  issue.Type=="warn_jump_out_of_scope" || issue.Type=="Rule6-6-2" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 6–4–4: A switch-label shall only be used when the most closely-enclosing compound statement is the body of a switch statement: A switch-label can be placed anywhere within the statements that form the body of a switch statement, potentially leading to unstructured code. To prevent this from happening, the scope of a case-label or default-label shall be the compound statement forming the body of a switchstatement. All case-clauses and the default-clause shall be at the same scope.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule6-4-4"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 6–4–5: An unconditional throw or break statement shall terminate every non-empty switch-clause: If a developer fails to add a break statement to the end of a switch-clause,then control flow “falls” into any following switch-clause. Whilst this is sometimes intentional, it is often an error.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_unannotated_fallthrough" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 6–4–6:The final clause of a switch statement shall be the default-clause: The requirement for a final default-clause is defensive programming. This clause shall either take appropriate action, or else contain a suitable comment as to why no action is taken.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule6-4-6"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 6–4–7: The condition of a switch statement shall not have bool type: An if statement gives a clearer representation for a Boolean choice.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_bool_switch_condition" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 6–4–8: Every switch statement shall have at least one case-clause: A switch statement with no case-clauses is redundant.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule6-4-8"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 6–6–1: Any label referenced by a goto statement shall be declared in the same block, or in a block enclosing the goto statement: Unconstrained use of goto can lead to programs that are extremely difficult to comprehend, analyse and, for C++, can also lead to the program exhibiting unspecified behaviour. However, in many cases a total ban on goto requires the introduction of flags to ensure correct control flow,and it is possible that these flags may themselves be less transparent than the goto they replace.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_jump_out_of_scope" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 6–6–2: The goto statement shall jump to a label declared later in the same function body: Unconstrained use of goto can lead to programs that are extremely difficult to comprehend,analyse and, for C++, can also lead to the program exhibiting unspecified behaviour. However, in many cases a total ban on goto requires the introduction of flags to ensure correct control flow, and it is possible that these flags may themselves be less transparent than the goto they replace.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where  issue.Type=="Rule6-6-2" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 6–6–5: A function shall have a single point of exit at the end of the function: This is required by IEC 61508 [12], as part of the requirements for a modular approach.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where  issue.Type=="Rule6-6-5" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

Declarations

Declarators

Classes

  • Rule 9–5–1: Unions shall not be used: The use of unions to access an object in different ways may result in the data being misinterpreted. Therefore, this rule prohibits the use of unions for any purpose.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule9-5-1"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 10–1–1: Classes should not be derived from virtual bases: The use of virtual base classes can introduce a number of undefined and potentially confusing behaviours. The use of virtual bases is not recommended.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule10-1-1"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 10–3–2: Each overriding virtual function shall be declared with the virtual keyword: Declaring overriding virtual functions with the virtual keyword removes the need to check the base class to determine whether a function is virtual.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule10-3-2"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 11–0–1: Member data in non-POD class types shall be private: By implementing class interfaces with member functions, the implementation retains more control over how the object state can be modified, and helps to allow a class to be maintained without affecting clients.

    This coding standard is computed with the following query:

    warnif count > 0 
    from f in JustMyCode.Fields where !f.ParentType.IsPOD && f.IsPublic
    select f

  • Rule 12–1–1: An object's dynamic type shall not be used from the body of its constructor or destructor: During construction and destruction of an object, its final type may be different to that of the completely constructed object. The result of using an object’s dynamic type in a constructor or destructor may not be consistent with developer expectations.

    This coding standard is computed with the following query:

    warnif count > 0 
    from m in JustMyCode.Methods where 
    (m.IsConstructor || m.IsDestructor)
    && (m.MethodsCalled.Where(vm=>vm.IsVirtual).Count()>0 || m.IsUsing("Keywords.dynamic_cast".AllowNoMatch()))
    select m

  • Rule 12–1–2: All constructors that are callable with a single argument of fundamental type shall be declared explicit: This rule reduces confusion over which constructor will be used, and with what parameters.

    This coding standard is computed with the following query:

    warnif count > 0 
    from m in JustMyCode.Methods where m.IsConstructor && m.Params.Count()==1 && m.Params.First().ParamType!=null
    && m.Params.First().ParamType.Name=="int" && !m.IsExplicitConstructor
    select m

  • Rule 12–8–2: The copy assignment operator shall be declared protected or private in an abstract class: An abstract class represents the interface part of a hierarchy. Invoking the copy constructor from the top of such a hierarchy bypasses the underlying implementation resulting in only the base sub-objects being copied.

    This coding standard is computed with the following query:

    warnif count > 0 
    from m in JustMyCode.Methods where m.SimpleName== "operator==" 
    && m.ParentType.IsAbstract && m.IsPublic 
    select m

Exceptions

  • Rule 15–0–2: An exception object should not have pointer type: If an exception object of pointer type is thrown and that pointer refers to a dynamically created object, then it may be unclear which function is responsible for destroying it, and when. This ambiguity does not exist if the object is caught by value or reference.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule15-0-2"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 15–3–2: There should be at least one exception handler to catch all otherwise unhandled exceptions: If a program throws an unhandled exception it terminates in an implementation-defined manner. In particular, it is implementation-defined whether the call stack is unwound, before termination, so the destructors of any automatic objects may or may not be executed.

    This coding standard is computed with the following query:

    warnif count > 0 
    from m in JustMyCode.Methods where m.IsEntryPoint
    && m.IsUsing("Keywords.generic_catch".AllowNoMatch()) select m

  • Rule 15–3–5: A class type exception shall always be caught by reference: If a class type exception object is caught by value, slicing occurs. That is, if the exception object is of a derived class and is caught as the base, only the base class’s functions (including virtual functions) can be called. Also, any additional member data in the derived class cannot be accessed.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="catchExceptionByValue"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 15–3–7: Where multiple handlers are provided in a single try-catch statement or function-try-block, any ellipsis (catch-all) handler shall occur last: If the catch-all handler is found before any other handler, that behaviour will be performed. Any handlers after the catch-all are unreachable code and can never be executed.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_exception_caught_by_earlier_handler" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 15–5–1: A class destructor shall not exit with an exception: When an exception is thrown, the call stack is unwound up to the point where the exception is to be handled. The destructors for all automatic objects declared between the point where the exception is thrown and where it is to be handled will be invoked.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="exceptThrowInDestructor"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

Preprocessor

  • Rule 16–0–3: #undef shall not be used: #undef should not normally be needed. Its use can lead to confusion with respect to the existence or meaning of a macro when it is used in the code.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_undef_used" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 16–0–7: Undefined macro identifiers shall not be used in #if or #elif preprocessor directives, except as operands to the defined operator: If an attempt is made to use an identifier in a preprocessor directive, and that identifier has not been defined, the preprocessor will assume the value zero.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_pp_undef_identifier" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 16–3–1: There shall be at most one occurrence of the # or ## operators in a single macro definition: The order of evaluation associated with both the # and ## preprocess or operators is unspecified. This problem can be avoided by having only one occurrence of either operator in any single macro definition(i.e.one#, or one ##or neither).

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_pp_hashhash_used" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 16–3–2: The # and ## operators should not be used: The order of evaluation associated with both the # and ## preprocessor operators is unspecified. Compilers have been known to implement these operators inconsistently, therefore, to avoid these problems, do not use them.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_pp_hash_used" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

Library

  • Rule 17–0–1: Reserved identifiers, macros and functions in the standard library shall not be defined, redefined or undefined: It is generally bad practice to #undef a macro that is defined in the standard library. It is also bad practice to #define a macro name that is a C++ reserved identifier, or C++ keyword or the name of any macro,object or function in the standard library. For example,there are some specific reserved words and function names that are known to give rise to undefined behaviour if they are redefined or undefined, including defined, __LINE__, __FILE__, __DATE__, __TIME__, __STDC__, errno and assert.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_reserved_id_macro" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 17–0–5: The setjmp macro and the longjmp function shall not be used: setjmp and longjmp allow the normal function call mechanisms to be bypassed, and shall not be used,since exception handling provides a better defined mechanism for this.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule17-0-5"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 18–0–1: The C library shall not be used: Some C++ libraries (e.g. ) also have corresponding C versions (e.g. ). This rule requires that the C++ version is used.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule18-0-1"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 18–0–2: The library functions atof, atoi and atol from library cstdlib shall not be used: These functions have undefined behaviour associated with them when the string cannot be converted.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule18-0-2"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 18–0–3: The library functions abort, exit, getenv and system from library cstdlib shall not be used: The use of these functions leads to implementation-defined behaviour.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule18-0-3"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 18–0–4:The time handling functions of library shall not be used: Various aspects are implementation-defined or unspecified, such as the formats of times.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule18-0-4"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 18–0–5: The unbounded functions of library cstring shall not be used: The strcpy, strcmp, strcat, strchr, strspn, strcspn, strpbrk, strrchr, strstr, strtok and strlen functions within the library can read or write beyond the end of a buffer, resulting in undefined behaviour.Ideally, a safe string handling library should be used.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule18-0-5"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 18–2–1: The macro offsetof shall not be used: Use of this macro can lead to undefined behaviour when the types of the operands are incompatible, or when bit fields are used.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule18-2-1"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 18–4–1: Dynamic heap memory allocation shall not be used: The use of dynamic memory can lead to out-of-storage run-time failures, which are undesirable. The built-in new and delete operators, other than the placement versions, use dynamic heap memory. The functions calloc, malloc, realloc and free also use dynamic heap memory.There is a range of unspecified, undefined and implementation-defined behaviour associated with dynamic memory allocation, as well as a number of other potential pitfalls. Dynamic heap memory allocation may lead to memory leaks, data inconsistency, memory exhaustion, non-deterministic behaviour.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule18-4-1"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 18–7–1: The signal handling facilities of csignal shall not be used: Signal handling contains implementation-defined and undefined behaviour.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule18-7-1"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 19–3–1: The error indicator errno shall not be used: errno is a facility of C++ which should in theory be useful, but which in practice is poorly defined by ISO/IEC 14882:2003 [1]. A non-zero value may or may not indicate that a problem has occurred; therefore errno shall not be used.Even for those functions for which the behaviour of errno is well defined, it is preferable to check the values of inputs before calling the function rather than relying on using errno to trap errors.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule19-3-1"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 27–0–1: The stream input/output library shall not be used: This includes file and I/O functions fgetpos, fopen, ftell, gets, perror, remove, rename, etc. Streams and file I/O have a large number of unspecified, undefined and implementation-defined behaviours associated with them.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule18-4-1"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

Go to top


CppDepend offers a wide range of features. It is often described as a Swiss Army Knife for C and C++ developers.

Start Free Trial