Misra C 2012 Standards
Introduction
MISRA is a collaboration between manufacturers, component suppliers and engineering consultancies which seeks to promote best practice in developing safety- and security-related electronic systems and other software-intensive applications.
To learn Misra C Standards, you can print this MISRA C:2012 Amendment 2 pdf
99 Queries in Misra C standards6 Uncessary Constructs, 2 Comments, 5 Identifiers and Lexical Conventions, 7 Declarations and defintions, 5 Pointer type conversions, 16 Expressions, 15 Statements, 9 Declarations, 6 Declarators, 7 Classes, 5 Exceptions, 4 Preprocessor, 12 Library.
Uncessary Constructs
-
Rule 2.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 2.2: There shall be no dead 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 2.3: 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 2.5: A project should not contain unused macro declarations:
If a macro is declared but not used, then it is unclear
to a reviewer if the macro is redundant or it hasbeen 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=="pp_macro_not_used" select
new { issue,issue.FilePath,Line=issue.BeginLine} -
Rule 2.6: A function should not contain unused label declarations:
If a label is declared but not used, then it is unclear
to a reviewer if the label is redundant or it hasbeen 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_label" select
new { issue,issue.FilePath,Line=issue.BeginLine} -
Rule 2.7: There shall be no unused parameters in 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"
select new { issue,issue.FilePath,Line=issue.BeginLine}
Comments
-
Rule 3.1: The character sequences /* and // shall not be used within a comment:
If a comment starting sequence, /* or // ,
occurs within a /* comment, is it quite likely to be causedby a missing*/
comment ending sequence.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 3.2: Line-splicing shall not be used in // comments:
Line-splicing occurs when the \ character is immediately followed by a new-line character.
If the source file contains multibyte characters, they are converted to the source character set before anysplicing occurs.
This coding standard is computed with the following query:
warnif count > 0
from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="ext_multi_line_line_comment" select
new { issue,issue.FilePath,Line=issue.BeginLine}
Identifiers and Lexical Conventions
-
Rule 4.2: 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 5.3: 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 5.7: A tag name shall be a unique identifier:
This coding standard is computed with the following query:
warnif count > 0
from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="err_use_with_wrong_tag" select
new { issue,issue.FilePath,Line=issue.BeginLine} -
Rule 7.2: 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 7.3: 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}
Declarations and defintions
-
Rule 8.1: Types shall be explicitly specified:
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 8.4:A compatible declaration shall be visible when an object or functionwith external linkage is defined:
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 8.11: 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 8.12: Within an enumerator list, the value of an implicitly-specifiedenumeration constant shall be unique:
// 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 9.1: The value of an object with automatic storage duration shall not beread before it has been set:
The intent of this rule is that all variables shall have been written to before they are read.
This does not necessarily require initialization at declaration.
This coding standard is computed with the following query:
warnif count > 0
from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_uninit_var" select
new { issue,issue.FilePath,Line=issue.BeginLine} -
Rule 9.2: The initializer for an aggregate or union shall be enclosed in braces:
The intent of this rule is that all variables shall have been written to before they are read.
This does not necessarily require initialization at declaration.
This coding standard is computed with the following query:
warnif count > 0
from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_uninit_var" select
new { issue,issue.FilePath,Line=issue.BeginLine} -
Rule 9.4: An element of an object shall not be initialized more than once:
The intent of this rule is that all variables shall have been written to before they are read.
This does not necessarily require initialization at declaration.
This coding standard is computed with the following query:
warnif count > 0
from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_uninit_var" select
new { issue,issue.FilePath,Line=issue.BeginLine}
Pointer type conversions
-
Rule 11.1: Conversions shall not be performed between a pointer to a functionand any other type:
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 11.5: A conversion should not be performed from pointer to void into pointer to object:
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 11.7: A cast shall not be performed between pointer to object and a non-integer arithmetic type:
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 11.8: A cast shall not remove any const or volatile qualification from the typepointed to by a pointer:
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 11.9 The macro NULLshall be the only permitted form of integer null pointer constant:
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}
Expressions
-
Rule 12.2: The right hand operand of a shift operator shall lie in the range zeroto one less than the width in bits of the essential type of the left handoperand:
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 12.3: 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 13.3: A 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:
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 13.4: The result of an assignment operator should not be used:
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 13.6: The operand of the sizeof operator shall not contain any expression which has potential side effects:
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:
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:
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:
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:
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} -
Rule5–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 -
Rule5–3–4: Evaluation of the operand to the sizeof operator shall not contain side effects:
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}
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} -
A loop counter shall not have essentially Floating type:
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
-
Rule 7-3-1: The global namespace shall only contain main, namespace declarations and extern "C" declarations:
This coding standard is computed with the following query:
warnif count > 0
from m in JustMyCode.Methods where m.SimpleName=="main" && m.ParentNamespace.Name!=""
select m -
Rule 7–3–2: The identifier main shall not be used for a function other than the global function main:
main (or its equivalent) is usually the entry point to the program and is the only identifier which must be in the global namespace.
The use of main for other functions may not meet developer expectations.
This coding standard is computed with the following query:
warnif count > 0
from m in JustMyCode.Methods where m.SimpleName=="main" && m.ParentNamespace.Name!=""
select m -
Rule 7–3–3: There shall be no unnamed namespaces in header files:
An unnamed namespace will be unique within each translation unit.
Any declarations appearing in an unnamed namespace in a header will refer to different entities in each translation unit,
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.Type=="Rule7-3-3"
select new { issue,issue.FilePath,Line=issue.BeginLine} -
Rule 7–3–4: using-directives shall not be used:
using-directives add additional scopes to the set of scopes searched during name lookup.
All identifiers in these scopes become visible, increasing the possibility that the identifier found by the compiler does not meet developer expectations.
This coding standard is computed with the following query:
warnif count > 0
from issue in ImportedIssues where issue.Type=="Rule7-3-4"
select new { issue,issue.FilePath,Line=issue.BeginLine} -
Rule 7–4–2: Assembler instructions shall only be introduced using the asm declaration:
This coding standard is computed with the following query:
warnif count > 0
from m in JustMyCode.Methods where m.SimpleName=="main" && m.ParentNamespace.Name!=""
select m -
Rule 7–4–3: Assembly language shall be encapsulated and isolated:
This coding standard is computed with the following query:
warnif count > 0
from m in JustMyCode.Methods where m.SimpleName=="main" && m.ParentNamespace.Name!=""
select m -
Rule 7–5–1: A function shall not return a reference or a pointer to an automatic variable(including parameters), defined within the function:
Automatic variables are destroyed at the end of the function call.
Returning a reference or pointer to such a variable allows it to be used after its destruction,
leading to undefined behaviour.
This coding standard is computed with the following query:
warnif count > 0
from issue in ImportedIssues where issue.ToolName=="CppCheck" && issue.Type=="returnAddressOfAutoVariable" select
new { issue,issue.FilePath,Line=issue.BeginLine} -
Rule 7–5–2: The 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:
If the address of an automatic object is assigned to another automatic object of larger scope,
or to a static object, or returned from a function,
then the object containing the address may exist beyond the time when the original object ceases to exist (and its address becomes invalid).
This coding standard is computed with the following query:
warnif count > 0
from issue in ImportedIssues where issue.ToolName=="CppCheck" && issue.Type=="deadpointer" select
new { issue,issue.FilePath,Line=issue.BeginLine} -
Rule 7-5-4: Functions should not call themselves, either directly or indirectly:
This coding standard is computed with the following query:
warnif count > 0
from issue in ImportedIssues where issue.ToolName=="CppCheck" && issue.Type=="deadpointer" select
new { issue,issue.FilePath,Line=issue.BeginLine}
Declarators
-
Rule 8–4–1: Functions shall not be defined using the ellipsis notation:
Passing arguments via an ellipsis bypasses the type checking performed by the compiler.
Additionally, passing an argument with non-POD class type leads to undefined behaviour.
This coding standard is computed with the following query:
warnif count > 0
from m in JustMyCode.Methods where m.IsVariadic
select m -
Rule 8–4–3: All exit paths from a function with non-void return type shall have an explicit return statement with an expression:
This expression gives the value that the function returns.
The absence of a return with an expression leads to undefined behaviour (and the compiler may not give 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_maybe_falloff_nonvoid_function" select
new { issue,issue.FilePath,Line=issue.BeginLine} -
Rule 8–4–4: A function identifier shall either be used to call the function or it shall be preceded by &:
This coding standard is computed with the following query:
warnif count > 0
from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_duplicate_enum_values" select
new { issue,issue.FilePath,Line=issue.BeginLine} -
Rule 8–5–1: All variables shall have a defined value before they are used:
The intent of this rule is that all variables shall have been written to before they are read.
This does not necessarily require initialization at declaration.
This coding standard is computed with the following query:
warnif count > 0
from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_uninit_var" select
new { issue,issue.FilePath,Line=issue.BeginLine} -
Rule 8–5–2: Braces shall be used to indicate and match the structure in the non-zero initialization of arrays and structures:
ISO/IEC 14882:2003 [1] requires initializer lists for arrays,
structures and union types to be enclosed in a single pair of braces(though the behaviour if this is not done is undefined).
This coding standard is computed with the following query:
warnif count > 0
from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_missing_braces" select
new { issue,issue.FilePath,Line=issue.BeginLine} -
Rule 8–5–3: In an enumerator list, the = construct shall not be used to explicitly initialize members other than the first, unless all items are explicitly initialized:
If an enumerator list is given with no explicit initialization of members,
then C++ allocates a sequence of integers starting at zero for the first element and increasing by one for each subsequent element.
This coding standard is computed with the following query:
warnif count > 0
from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_duplicate_enum_values" select
new { issue,issue.FilePath,Line=issue.BeginLine}
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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 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}