JSF AV C++ Coding Rules

Supported JSF C++ Coding Rules

Code Size and Complexity

N. JSF^®++ Definition Polyspace^® Implementation

N.	JSF^®++ Definition	Polyspace^® Implementation
1	Any one function (or method) will contain no more than 200 logical source lines of code (L-SLOCs).	Message in report file: `<function name>` has `<num>` logical source lines of code.
3	All functions shall have a cyclomatic complexity number of 20 or less.	Message in report file: `<function name>` has cyclomatic complexity number equal to `<num>`.

Any one function (or method) will contain no more than 200 logical source lines of code (L-SLOCs).

Message in report file:

<function name> has <num> logical source lines of code.

All functions shall have a cyclomatic complexity number of 20 or less.

Message in report file:

<function name> has cyclomatic complexity number equal to <num>.

Environment

N.	JSF++ Definition	Polyspace Implementation
8	All code shall conform to ISO/IEC 14882:2002(E) standard C++.	Reports the compilation error message
9	Only those characters specified in the C++ basic source character set will be used.
11	Trigraphs will not be used.
12	The following digraphs will not be used: `<%`, `%>`, `<:`, `:>`, `%:`, `%:%:`.	Message in report file: The following digraph will not be used: `<digraph>`. Reports the digraph. If the rule level is set to warning, the digraph will be allowed even if it is not supported in `-compiler iso`.
13	Multi-byte characters and wide string literals will not be used.	Report `L'c'`, `L"string"`, and use of `wchar_t`.
14	Literal suffixes shall use uppercase rather than lowercase letters.
15	Provision shall be made for run-time checking (defensive programming).	Done with checks in the software.

Libraries

N.	JSF++ Definition	Polyspace Implementation
17	The error indicator `errno` shall not be used.	`errno` should not be used as a macro or a global with external "C" linkage.
18	The macro `offsetof`, in library `<stddef.h>`, shall not be used.	`offsetof` should not be used as a macro or a global with external "C" linkage.
19	`<locale.h>` and the `setlocale` function shall not be used.	`setlocale` and `localeconv` should not be used as a macro or a global with external "C" linkage.
20	The `setjmp` macro and the `longjmp` function shall not be used.	`setjmp` and `longjmp` should not be used as a macro or a global with external "C" linkage.
21	The signal handling facilities of `<signal.h>` shall not be used.	`signal` and `raise` should not be used as a macro or a global with external "C" linkage.
22	The input/output library `<stdio.h>` shall not be used.	all standard functions of `<stdio.h>` should not be used as a macro or a global with external "C" linkage.
23	The library functions `atof`, `atoi` and `atol` from library `<stdlib.h>` shall not be used.	`atof`, `atoi` and `atol` should not be used as a macro or a global with external "C" linkage.
24	The library functions `abort`, `exit`, `getenv` and `system` from library `<stdlib.h>` shall not be used.	`abort`, `exit`, `getenv` and `system` should not be used as a macro or a global with external "C" linkage.
25	The time handling functions of library `<time.h>` shall not be used.	`clock`, `difftime`, `mktime`, `asctime`, `ctime`, `gmtime`, `localtime` and `strftime` should not be used as a macro or a global with external "C" linkage.

Pre-Processing Directives

N.	JSF++ Definition	Polyspace Implementation
26	Only the following preprocessor directives shall be used: `#ifndef`, `#define`, `#endif`, `#include`.
27	`#ifndef`, `#define` and `#endif` will be used to prevent multiple inclusions of the same header file. Other techniques to prevent the multiple inclusions of header files will not be used.	Detects the patterns `#if !defined`, `#pragma once`, `#ifdef`, and missing`#define`.
28	The `#ifndef` and `#endif` preprocessor directives will only be used as defined in AV Rule 27 to prevent multiple inclusions of the same header file.	Detects any use that does not comply with AV Rule 27. Assuming 35/27 is not violated, reports only `#ifndef`.
29	The `#define` preprocessor directive shall not be used to create inline macros. Inline functions shall be used instead.	Rule is split into two parts: the definition of a macro function (29.def) and the call of a macrofunction (29.use). Messages in report file: 29.1 : The `#define` preprocessor directive shall not be used to create inline macros. 29.2 : Inline functions shall be used instead of inline macros.
30	The `#define` preprocessor directive shall not be used to define constant values. Instead, the `const` qualifier shall be applied to variable declarations to specify constant values.	Reports `#define` of simple constants.
31	The `#define` preprocessor directive will only be used as part of the technique to prevent multiple inclusions of the same header file.	Detects use of `#define` that are not used to guard for multiple inclusion, assuming that rules 35 and 27 are not violated.
32	The `#include` preprocessor directive will only be used to include header (*.h) files.

Header Files

N.	JSF++ Definition	Polyspace Implementation
33	The `#include` directive shall use the `<filename.h>` notation to include header files.
35	A header file will contain a mechanism that prevents multiple inclusions of itself.
39	Header files (`.h`) will not* contain non-const variable definitions or function definitions.	Reports definitions of global variables / function in header.

Style

N.	JSF++ Definition	Polyspace Implementation
40	Every implementation file shall include the header files that uniquely define the inline functions, types, and templates used.	Reports when type, template, or inline function is defined in source file.
41	Source lines will be kept to a length of 120 characters or less.	Polyspace ignores the newline character (`\n`) when counting the line length.
42	Each expression-statement will be on a separate line.	Reports when two consecutive expression statements are on the same line (unless the statements are part of a macro definition).
43	Tabs should be avoided.
44	All indentations will be at least two spaces and be consistent within the same source file.	Reports when a statement indentation is not at least two spaces more than the statement containing it. Does not report bad indentation between opening braces following if/else, do/while, for, and while statements. NB: in final release it will accept any indentation
46	User-specified identifiers (internal and external) will not rely on significance of more than 64 characters.	This checker is deactivated in a default Polyspace as You Code analysis. See Checkers Deactivated in Polyspace as You Code Analysis (Polyspace Access).
47	Identifiers will not begin with the underscore character '`_`'.
48	Identifiers will not differ by: Only a mixture of case The presence/absence of the underscore character The interchange of the letter 'O'; with the number '0' or the letter 'D' The interchange of the letter 'I'; with the number '1' or the letter 'l' The interchange of the letter 'S' with the number '5' The interchange of the letter 'Z' with the number 2 The interchange of the letter 'n' with the letter 'h'	Checked regardless of scope. Not checked between macros and other identifiers. Messages in report file: Identifier `Idf1` (`file1.cpp line l1 column c1`) and `Idf2` (`file2.cpp line l2 column c2`) only differ by the presence/absence of the underscore character. Identifier `Idf1` (`file1.cpp line l1 column c1`) and `Idf2` (`file2.cpp line l2 column c2`) only differ by a mixture of case. Identifier `Idf1` (`file1.cpp line l1 column c1`) and `Idf2` (`file2.cpp line l2 column c2`) only differ by letter `O`, with the number `0`.
50	The first word of the name of a class, structure, namespace, enumeration, or type created with `typedef` will begin with an uppercase letter. All others letters will be lowercase.	Messages in report file: The first word of the name of a class will begin with an uppercase letter. The first word of the namespace of a class will begin with an uppercase letter.
51	All letters contained in function and variables names will be composed entirely of lowercase letters.	Messages in report file: All letters contained in variable names will be composed entirely of lowercase letters. All letters contained in function names will be composed entirely of lowercase letters.
52	Identifiers for constant and enumerator values shall be lowercase.	Messages in report file: Identifier for enumerator value shall be lowercase. Identifier for template constant parameter shall be lowercase.
53	Header files will always have file name extension of "`.h`".	`.H` is allowed if you set the option `-dos`.
53.1	The following character sequences shall not appear in header file names: `'`, `\`, `/*`, `//`, or `"`.
54	Implementation files will always have a file name extension of ".cpp".	Not case sensitive if you set the option `-dos`.
57	The public, protected, and private sections of a class will be declared in that order.
58	When declaring and defining functions with more than two parameters, the leading parenthesis and the first argument will be written on the same line as the function name. Each additional argument will be written on a separate line (with the closing parenthesis directly after the last argument).	Detects that two parameters are not on the same line, The first parameter should be on the same line as function name. Does not check for the closing parenthesis.
59	The statements forming the body of an if, else if, else, while, do ... while or for statement shall always be enclosed in braces, even if the braces form an empty block.	Messages in report file: The statements forming the body of an if statement shall always be enclosed in braces. The statements forming the body of an else statement shall always be enclosed in braces. The statements forming the body of a while statement shall always be enclosed in braces. The statements forming the body of a do ... while statement shall always be enclosed in braces. The statements forming the body of a for statement shall always be enclosed in braces.
60	Braces ("`{}`") which enclose a block will be placed in the same column, on separate lines directly before and after the block.	Detects that statement-block braces should be in the same columns.
61	Braces ("`{}`") which enclose a block will have nothing else on the line except comments.
62	The dereference operator ‘*’ and the address-of operator ‘&’ will be directly connected with the type-specifier.	Reports when there is a space between type and "*" "&" for variables, parameters and fields declaration.
63	Spaces will not be used around ‘.’ or ‘->’, nor between unary operators and operands.	Reports when the following characters are not directly connected to a white space: . -> ! ~ - ++ — Note that a violation will be reported for “.” used in float/double definition.

Classes

N.	JSF++ Definition	Polyspace Implementation
67	Public and protected data should only be used in structs - not classes.
68	Unneeded implicitly generated member functions shall be explicitly disallowed.	Reports when default constructor, assignment operator, copy constructor or destructor is not declared.
71.1	A class’s virtual functions shall not be invoked from its destructor or any of its constructors.	Reports when a constructor or destructor directly calls a virtual function.
74	Initialization of nonstatic class members will be performed through the member initialization list rather than through assignment in the body of a constructor.	All data should be initialized in the initialization list except for array. Does not report that an assignment exists in `ctor` body. Message in report file: Initialization of nonstatic class members "`<field>`" will be performed through the member initialization list.
75	Members of the initialization list shall be listed in the order in which they are declared in the class.
76	A copy constructor and an assignment operator shall be declared for classes that contain pointers to data items or nontrivial destructors.	Messages in report file: `no copy constructor and no copy assign` `no copy constructor` `no copy assign`
77.1	The definition of a member function shall not contain default arguments that produce a signature identical to that of the implicitly-declared copy constructor for the corresponding class/structure.	Does not report when an explicit copy constructor exists.
78	All base classes with a virtual function shall define a virtual destructor.
79	All resources acquired by a class shall be released by the class’s destructor.	Reports when the number of “new” called in a constructor is greater than the number of “delete” called in its destructor. Note A violation is raised even if “new” is done in a “if/else”.
81	The assignment operator shall handle self-assignment correctly	Reports when copy assignment body does not begin with “`if (this != arg)`” A violation is not raised if an empty `else` statement follows the `if`, or the body contains only a return statement. A violation is raised when the `if` statement is followed by a statement other than the return statement.
82	An assignment operator shall return a reference to `*this`.	The following operators should return `this` on method, and `first_arg` on plain function: `operator=` `operator+=` `operator-=` `operator=` `operator >>=` `operator <<=` `operator /=` `operator %=` `operator \|=` `operator &=` `operator ^=` Prefix `operator++` Prefix `operator--` Does not report when no return exists. No special message if type does not match. Messages in report file: An assignment operator shall return a reference to `this`. An assignment operator shall return a reference to its first arg.
83	An assignment operator shall assign all data members and bases that affect the class invariant (a data element representing a cache, for example, would not need to be copied).	Reports when a copy assignment does not assign all data members. In a derived class, it also reports when a copy assignment does not call inherited copy assignments.
88	Multiple inheritance shall only be allowed in the following restricted form: `n` interfaces plus `m` private implementations, plus at most one protected implementation.	Messages in report file: Multiple inheritance on public implementation shall not be allowed: `<public_base_class>` is not an interface. Multiple inheritance on protected implementation shall not be allowed : `<protected_base_class_1>`. `<protected_base_class_2>` are not interfaces.
88.1	A stateful virtual base shall be explicitly declared in each derived class that accesses it.
89	A base class shall not be both virtual and nonvirtual in the same hierarchy.
94	An inherited nonvirtual function shall not be redefined in a derived class.	Does not report for destructor. Message in report file: Inherited nonvirtual function `%s` shall not be redefined in a derived class.
95	An inherited default parameter shall never be redefined.
96	Arrays shall not be treated polymorphically.	Reports pointer arithmetic and array like access on expressions whose pointed type is used as a base class.
97	Arrays shall not be used in interface.	Only to prevent array-to-pointer-decay. Not checked on private methods
97.1	Neither operand of an equality operator (`==` or `!=`) shall be a pointer to a virtual member function.	Reports `==` and `!=` on pointer to member function of polymorphic classes (cannot determine statically if it is virtual or not), except when one argument is the null constant.

Namespaces

N.	JSF++ Definition	Polyspace Implementation
98	Every nonlocal name, except `main()`, should be placed in some namespace.
99	Namespaces will not be nested more than two levels deep.

Templates

N.	JSF++ Definition	Polyspace Implementation
104	A template specialization shall be declared before its use.	Reports the actual compilation error message.

Functions

N.	JSF++ Definition	Polyspace Implementation
107	Functions shall always be declared at file scope.
108	Functions with variable numbers of arguments shall not be used.
109	A function definition should not be placed in a class specification unless the function is intended to be inlined.	Reports when "inline" is not in the definition of a member function inside the class definition.
110	Functions with more than 7 arguments will not be used.
111	A function shall not return a pointer or reference to a non-static local object.	Simple cases without alias effect detected.
113	Functions will have a single exit point.	Reports first return, or once per function.
114	All exit points of value-returning functions shall be through return statements.
116	Small, concrete-type arguments (two or three words in size) should be passed by value if changes made to formal parameters should not be reflected in the calling function.	Report constant parameters references with `sizeof <= 2 * sizeof(int)`. Does not report for copy-constructor.
117	Arguments should be passed by reference if NULL values are not possible: 117.1: An object should be passed as `const T&` if the function should not change the value of the object. 117.2: An object should be passed as `T&` if the function may change the value of the object.	The checker flags a parameter passed by pointer if the parameter is not compared against `NULL` or `nullptr` in the function body. The absence of a check for null indicates that the parameter cannot be null and therefore can be passed by reference. The checker does not raise a violation: If a parameter is passed using a smart pointer. Only raw pointers are considered. If the pointer parameter is not dereferenced within the function.
119	Functions shall not call themselves, either directly or indirectly (i.e. recursion shall not be allowed).	The checker reports each function that calls itself, directly or indirectly. Even if several functions are involved in one recursion cycle, each function is individually reported. You can calculate the total number of recursion cycles using the code complexity metric `Number of Recursions`. Note that unlike the checker, the metric also considers implicit calls, for instance, to compiler-generated constructors during object creation.
121	Only functions with 1 or 2 statements should be considered candidates for inline functions.	Reports inline functions with more than 2 statements.
122	Trivial accessor and mutator functions should be inlined.	The checker uses the following criteria to determine if a method is trivial: An accessor method is trivial if it has no parameters and contains one `return` statement that returns a non-static data member or a reference to a non-static data member. The return type of the method must exactly match or be a reference to the type of the data member. A mutator method is trivial if it has a `void` return type, one parameter and contains one assignment statement that assigns the parameter to a non-static data member. The parameter type must exactly match or be a reference to the type of the data member. The checker reports trivial accessor and mutator methods defined outside their classes without the `inline` keyword. The checker does not flag template methods or virtual methods.

Comments

N. JSF++ Definition Polyspace Implementation

126 Only valid C++ style comments (//) shall be used.

127

Code that is not used (commented out) shall be deleted.

N.	JSF++ Definition	Polyspace Implementation
126	Only valid C++ style comments (`//`) shall be used.
127	Code that is not used (commented out) shall be deleted.	The checker uses internal heuristics to detect commented out code. For instance, characters such as `#`, `;`, `{` or `}` indicate comments that might potentially contain code. These comments are then evaluated against other metrics to determine the likelihood of code masquerading as comment. For instance, several successive words without a symbol in between reduces this likelihood. The checker does not flag the following comments even if they contain code: Doxygen comments beginning with `/*`, `/!`, `///` or `//!`. Comments that repeat the same symbol several times, for instance, the symbol `=` here: // ================================ // A comment // ================================/ Comments on the first line of a file. Comments that mix the C style (`/ */`) and C++ style (`//`). The checker considers that these comments are meant for documentation purposes or entered deliberately with some forethought.
133	Every source file will be documented with an introductory comment that provides information on the file name, its contents, and any program-required information (e.g. legal statements, copyright information, etc).	Reports when a file does not begin with two comment lines. Note: This rule cannot be annotated in the source code.

The checker uses internal heuristics to detect commented out code. For instance, characters such as #, ;, { or } indicate comments that might potentially contain code. These comments are then evaluated against other metrics to determine the likelihood of code masquerading as comment. For instance, several successive words without a symbol in between reduces this likelihood.

The checker does not flag the following comments even if they contain code:

Doxygen comments beginning with /**, /*!, /// or //!.
Comments that repeat the same symbol several times, for instance, the symbol = here:
```
// ================================
// A comment
// ================================*/
```
Comments on the first line of a file.
Comments that mix the C style (/* */) and C++ style (//).

The checker considers that these comments are meant for documentation purposes or entered deliberately with some forethought.

133

Every source file will be documented with an introductory comment that provides information on the file name, its contents, and any program-required information (e.g. legal statements, copyright information, etc).

Reports when a file does not begin with two comment lines.

Note: This rule cannot be annotated in the source code.

Declarations and Definitions

N.	JSF++ Definition	Polyspace Implementation
135	Identifiers in an inner scope shall not use the same name as an identifier in an outer scope, and therefore hide that identifier.
136	Declarations should be at the smallest feasible scope.	Reports when: A global variable is used in only one function. A local variable is not used in a statement (`expr`, `return`, `init` …) of the same level of its declaration (in the same block) or is not used in two sub-statements of its declaration. Note Non-used variables are reported. Initializations at definition are ignored (not considered an access)
137	All declarations at file scope should be static where possible.	Starting in R2021a, this checker is raised on declarations of nonstatic objects that you use in only one file. The checker is raised even if you analyze a singe file. The checker is not raised on the declarations of objects that remain unused, such as: Noninstantiated templates Uncalled `static` or `extern` functions Uncalled and undefined local functions Unused types and variables This checker is deactivated in a default Polyspace as You Code analysis. See Checkers Deactivated in Polyspace as You Code Analysis (Polyspace Access).
138	Identifiers shall not simultaneously have both internal and external linkage in the same translation unit.
139	External objects will not be declared in more than one file.	Reports all duplicate declarations inside a translation unit. Reports when the declaration localization is not the same in all translation units.
140	The register storage class specifier shall not be used.
141	A class, structure, or enumeration will not be declared in the definition of its type.

Initialization

N. JSF++ Definition Polyspace Implementation

142

N.	JSF++ Definition	Polyspace Implementation
142	All variables shall be initialized before use.	Polyspace reports a violation of this rule if your code contains these issues: `Non-initialized variable` `Member not initialized in constructor` `Non-initialized pointer`
144	Braces shall be used to indicate and match the structure in the non-zero initialization of arrays and structures.	This covers partial initialization.
145	In an enumerator list, the '`=`' construct shall not be used to explicitly initialize members other than the first, unless all items are explicitly initialized.	Generates one report for an enumerator list.

All variables shall be initialized before use.

Polyspace reports a violation of this rule if your code contains these issues:

144 Braces shall be used to indicate and match the structure in the non-zero initialization of arrays and structures. This covers partial initialization.

145 In an enumerator list, the '=' construct shall not be used to explicitly initialize members other than the first, unless all items are explicitly initialized. Generates one report for an enumerator list.

Types

N.	JSF++ Definition	Polyspace Implementation
147	The underlying bit representations of floating point numbers shall not be used in any way by the programmer.	Reports on casts with float pointers (except with `void*`).
148	Enumeration types shall be used instead of integer types (and constants) to select from a limited series of choices.	Reports when non enumeration types are used in switches.

Constants

N.	JSF++ Definition	Polyspace Implementation
149	Octal constants (other than zero) shall not be used.
150	Hexadecimal constants will be represented using all uppercase letters.
151	Numeric values in code will not be used; symbolic values will be used instead.	Reports direct numeric constants (except integer/float value `1, 0`) in expressions, non `-const` initializations. and switch cases. char constants are allowed. Does not report on templates non-type parameter.
151.1	A string literal shall not be modified.	The rule checker flags assignment of string literals to: Pointers other than pointers to `const` objects. Arrays that are not `const`-qualified.

Variables

N.	JSF++ Definition	Polyspace Implementation
152	Multiple variable declarations shall not be allowed on the same line.	Reports when two consecutive declaration statements are on the same line (unless the statements are part of a macro definition).

Unions and Bit Fields

N.	JSF++ Definition	Polyspace Implementation
153	Unions shall not be used.
154	Bit-fields shall have explicitly unsigned integral or enumeration types only.
156	All the members of a structure (or class) shall be named and shall only be accessed via their names.	Reports unnamed bit-fields (unnamed fields are not allowed).

Operators

N.	JSF++ Definition	Polyspace Implementation
157	The right hand operand of a `&&` or `\|\|` operator shall not contain side effects.	Assumes rule 159 is not violated. Messages in report file: The right hand operand of a `&&` operator shall not contain side effects. The right hand operand of a `\|\|` operator shall not contain side effects.
158	The operands of a logical `&&` or `\|\|` shall be parenthesized if the operands contain binary operators.	Messages in report file: The operands of a logical `&&` shall be parenthesized if the operands contain binary operators. The operands of a logical `\|\|` shall be parenthesized if the operands contain binary operators. Exception for: `X \|\| Y \|\| Z` , `Z&&Y &&Z`
159	Operators `\|\|`, `&&`, and unary `&` shall not be overloaded.	Messages in report file: Unary operator & shall not be overloaded. Operator `\|\|` shall not be overloaded. Operator `&&` shall not be overloaded.
160	An assignment expression shall be used only as the expression in an expression statement.	Only simple assignment, not `+=`, `++`, etc.
162	Signed and unsigned values shall not be mixed in arithmetic or comparison operations.
163	Unsigned arithmetic shall not be used.
164	The right hand operand of a shift operator shall lie between zero and one less than the width in bits of the left-hand operand (inclusive).
164.1	The left-hand operand of a right-shift operator shall not have a negative value.	Detects constant case `+`. Found by the software for dynamic cases.
165	The unary minus operator shall not be applied to an unsigned expression.
166	The `sizeof` operator will not be used on expressions that contain side effects.
168	The comma operator shall not be used.

Pointers and References

N.	JSF++ Definition	Polyspace Implementation
169	Pointers to pointers should be avoided when possible.	Reports second-level pointers, except for arguments of main.
170	More than 2 levels of pointer indirection shall not be used.	Only reports on variables/parameters.
171	Relational operators shall not be applied to pointer types except where both operands are of the same type and point to: the same object, the same function, members of the same object, or elements of the same array (including one past the end of the same array).	Reports when relational operator are used on pointer types (casts ignored).
173	The address of an object with automatic storage shall not be assigned to an object which persists after the object has ceased to exist.
174	The null pointer shall not be de-referenced.	Done with checks in software.
175	A pointer shall not be compared to `NULL` or be assigned `NULL`; use plain `0` instead.	Reports usage of `NULL` macro in pointer contexts.
176	A `typedef` will be used to simplify program syntax when declaring function pointers.	Reports non-`typedef` function pointers, or pointers to member functions for types of variables, fields, parameters. Returns type of function, cast, and exception specification.

Type Conversions

N.	JSF++ Definition	Polyspace Implementation
177	User-defined conversion functions should be avoided.	Reports user defined conversion function, non-explicit constructor with one parameter or default value for others (even undefined ones). Does not report copy-constructor. Additional message for constructor case: This constructor should be flagged as "explicit".
178	Down casting (casting from base to derived class) shall only be allowed through one of the following mechanism: Virtual functions that act like dynamic casts (most likely useful in relatively simple cases). Use of the visitor (or similar) pattern (most likely useful in complicated cases).	Reports explicit down casting, dynamic_cast included. (Visitor patter does not have a special case.)
179	A pointer to a virtual base class shall not be converted to a pointer to a derived class.	Reports this specific down cast. Allows dynamic_cast.
180	Implicit conversions that may result in a loss of information shall not be used.	Reports the following implicit casts : `integer => smaller integer unsigned => smaller or eq signed signed => smaller or eq un-signed integer => float float => integer` Does not report for cast to `bool` reports for implicit cast on constant done with the option `-scalar-overflows-checks signed-and-unsigned`
181	Redundant explicit casts will not be used.	Reports useless cast: `cast T to T`. Casts to equivalent `typedefs` are also reported.
182	Type casting from any type to or from pointers shall not be used.	Does not report when Rule 181 applies.
184	Floating point numbers shall not be converted to integers unless such a conversion is a specified algorithmic requirement or is necessary for a hardware interface.	Reports `float->int` conversions. Does not report implicit ones.
185	C++ style casts (`const_cast`, `reinterpret_cast`, and `static_cast`) shall be used instead of the traditional C-style casts.

Flow Control Standards

N.	JSF++ Definition	Polyspace Implementation
186	There shall be no unreachable code.	Done with gray checks in the software.
187	All non-null statements shall potentially have a side-effect.
188	Labels will not be used, except in switch statements.
189	The `goto` statement shall not be used.
190	The `continue` statement shall not be used.
191	The `break` statement shall not be used (except to terminate the cases of a switch statement).
192	All `if`, `else if` constructs will contain either a final `else` clause or a comment indicating why a final `else` clause is not necessary.	`else if` should contain an `else` clause.
193	Every non-empty `case` clause in a switch statement shall be terminated with a `break` statement.
194	All `switch` statements that do not intend to test for every enumeration value shall contain a final `default` clause.	Reports only for missing `default`.
195	A `switch` expression will not represent a Boolean value.
196	Every `switch` statement will have at least two cases and a potential `default`.
197	Floating point variables shall not be used as loop counters.	Assumes 1 loop parameter.
198	The initialization expression in a `for` loop will perform no actions other than to initialize the value of a single `for` loop parameter.	Reports if `loop` parameter cannot be determined. Assumes Rule 200 is not violated. The `loop variable` parameter is assumed to be a variable.
199	The increment expression in a `for` loop will perform no action other than to change a single loop parameter to the next value for the loop.	Assumes 1 loop parameter (Rule 198), with non class type. Rule 200 must not be violated for this rule to be reported.
200	Null initialize or increment expressions in `for` loops will not be used; a `while` loop will be used instead.
201	Numeric variables being used within a for loop for iteration counting shall not be modified in the body of the loop.	Assumes 1 loop parameter (AV rule 198), and no alias writes.

Expressions

N.	JSF++ Definition	Polyspace Implementation
202	Floating point variables shall not be tested for exact equality or inequality.	Reports only direct equality/inequality. Check done for all expressions.
203	Evaluation of expressions shall not lead to overflow/underflow.	Done with overflow checks in the software.
204	A single operation with side-effects shall only be used in the following contexts: by itself the right-hand side of an assignment a condition the only argument expression with a side-effect in a function call condition of a loop switch condition single part of a chained operation	Reports when: A side effect is found in a return statement A side effect exists on a single value, and only one operand of the function call has a side effect.
204.1	The value of an expression shall be the same under any order of evaluation that the standard permits.	Reports when: A variable is written and reused within the same expression. A volatile variable is accessed more than once.
205	The volatile keyword shall not be used unless directly interfacing with hardware.	Reports if volatile keyword is used.

Memory Allocation

N.	JSF++ Definition	Polyspace Implementation
206	Allocation/deallocation from/to the free store (heap) shall not occur after initialization.	Reports calls to C library functions: `malloc` / `calloc` / `realloc` / `free` and all `new/delete` operators in functions or methods.

Fault Handling

N.	JSF++ Definition	Polyspace Implementation
208	C++ exceptions shall not be used.	Reports `try`, `catch`, `throw spec`, and `throw`.

Portable Code

N. JSF++ Definition Polyspace Implementation

209

N.	JSF++ Definition	Polyspace Implementation
209	The basic types of `int`, `short`, `long`, `float` and `double` shall not be used, but specific-length equivalents should be `typedef`'d accordingly for each compiler, and these type names used in the code.	Only allows use of basic types through direct `typedefs`.
213	No dependence shall be placed on C++’s operator precedence rules, below arithmetic operators, in expressions.	Reports when a binary operation has one operand that is not parenthesized and is an operation with inferior precedence level. Reports bitwise and shifts operators that are used without parenthesis and binary operation arguments.
215	Pointer arithmetic will not be used.	Reports:`p + Ip - Ip++p--p+=p-=` Allows `p[i]`.

The basic types of int, short, long, float and double shall not be used, but specific-length equivalents should be typedef'd accordingly for each compiler, and these type names used in the code.

Only allows use of basic types through direct typedefs.

213

No dependence shall be placed on C++’s operator precedence rules, below arithmetic operators, in expressions.

Reports when a binary operation has one operand that is not parenthesized and is an operation with inferior precedence level.

Reports bitwise and shifts operators that are used without parenthesis and binary operation arguments.

215

Pointer arithmetic will not be used.

Reports:p + Ip - Ip++p--p+=p-=

Allows p[i].

Unsupported JSF++ Rules

Code Size and Complexity
Rules
Environment
Libraries
Header Files
Style
Classes
Namespaces
Templates
Functions
Comments
Initialization
Types
Unions and Bit Fields
Operators
Type Conversions
Expressions
Memory Allocation
Portable Code
Efficiency Considerations
Miscellaneous
Testing

Code Size and Complexity

N.	JSF++ Definition
2	There shall not be any self-modifying code.

Rules

N.	JSF++ Definition
4	To break a “should” rule, the following approval must be received by the developer: approval from the software engineering lead (obtained by the unit approval in the developmental CM tool)
5	To break a “will” or a “shall” rule, the following approvals must be received by the developer: approval from the software engineering lead (obtained by the unit approval in the developmental CM tool) approval from the software product manager (obtained by the unit approval in the developmental CM tool)
6	Each deviation from a “shall” rule shall be documented in the file that contains the deviation. Deviations from this rule shall not be allowed, AV Rule 5 notwithstanding.
7	Approval will not be required for a deviation from a “shall” or “will” rule that complies with an exception specified by that rule.

Environment

N.	JSF++ Definition
10	Values of character types will be restricted to a defined and documented subset of ISO 10646 1.

Libraries

N.	JSF++ Definition
16	Only DO-178B level A [15] certifiable or SEAL 1 C/C++ libraries shall be used with safety-critical (i.e. SEAL 1) code.

Header Files

N.	JSF++ Definition
34	Header files should contain logically related declarations only.
36	Compilation dependencies should be minimized when possible.
37	Header (include) files should include only those header files that are required for them to successfully compile. Files that are only used by the associated .cpp file should be placed in the .cpp file — not the .h file.
38	Declarations of classes that are only accessed via pointers (*) or references (&) should be supplied by forward headers that contain only forward declarations.

Style

N.	JSF++ Definition
45	All words in an identifier will be separated by the ‘_’ character.
49	All acronyms in an identifier will be composed of uppercase letters.
55	The name of a header file should reflect the logical entity for which it provides declarations.
56	The name of an implementation file should reflect the logical entity for which it provides definitions and have a “.cpp” extension (this name will normally be identical to the header file that provides the corresponding declarations.) At times, more than one .cpp file for a given logical entity will be required. In these cases, a suffix should be appended to reflect a logical differentiation.

Classes

N.	JSF++ Definition
64	A class interface should be complete and minimal.
65	A structure should be used to model an entity that does not require an invariant.
66	A class should be used to model an entity that maintains an invariant.
69	A member function that does not affect the state of an object (its instance variables) will be declared const. Member functions should be const by default. Only when there is a clear, explicit reason should the const modifier on member functions be omitted.
70	A class will have friends only when a function or object requires access to the private elements of the class, but is unable to be a member of the class for logical or efficiency reasons.
70.1	An object shall not be improperly used before its lifetime begins or after its lifetime ends.
71	Calls to an externally visible operation of an object, other than its constructors, shall not be allowed until the object has been fully initialized.
72	The invariant for a class should be: A part of the postcondition of every class constructor, A part of the precondition of the class destructor (if any), A part of the precondition and postcondition of every other publicly accessible operation.
73	Unnecessary default constructors shall not be defined.
77	A copy constructor shall copy all data members and bases that affect the class invariant (a data element representing a cache, for example, would not need to be copied).
80	The default copy and assignment operators will be used for classes when those operators offer reasonable semantics.
84	Operator overloading will be used sparingly and in a conventional manner.
85	When two operators are opposites (such as == and !=), both will be defined and one will be defined in terms of the other.
86	Concrete types should be used to represent simple independent concepts.
87	Hierarchies should be based on abstract classes.
90	Heavily used interfaces should be minimal, general and abstract.
91	Public inheritance will be used to implement “is-a” relationships.
92	A subtype (publicly derived classes) will conform to the following guidelines with respect to all classes involved in the polymorphic assignment of different subclass instances to the same variable or parameter during the execution of the system: Preconditions of derived methods must be at least as weak as the preconditions of the methods they override. Postconditions of derived methods must be at least as strong as the postconditions of the methods they override. In other words, subclass methods must expect less and deliver more than the base class methods they override. This rule implies that subtypes will conform to the Liskov Substitution Principle.
93	“has-a” or “is-implemented-in-terms-of” relationships will be modeled through membership or non-public inheritance.

Namespaces

N.	JSF++ Definition
100	Elements from a namespace should be selected as follows: using declaration or explicit qualification for few (approximately five) names, using directive for many names.

Templates

N.	JSF++ Definition
101	Templates shall be reviewed as follows: with respect to the template in isolation considering assumptions or requirements placed on its arguments. with respect to all functions instantiated by actual arguments.
102	Template tests shall be created to cover all actual template instantiations.
103	Constraint checks should be applied to template arguments.
105	A template definition’s dependence on its instantiation contexts should be minimized.
106	Specializations for pointer types should be made where appropriate.

Functions

N.	JSF++ Definition
112	Function return values should not obscure resource ownership.
115	If a function returns error information, then that error information will be tested.
118	Arguments should be passed via pointers if NULL values are possible: 118.1 – An object should be passed as `const T` if its value should not be modified. 118.2* – An object should be passed as `T*` if its value may be modified.
120	Overloaded operations or methods should form families that use the same semantics, share the same name, have the same purpose, and that are differentiated by formal parameters.
123	The number of accessor and mutator functions should be minimized.
124	Trivial forwarding functions should be inlined.
125	Unnecessary temporary objects should be avoided.

Comments

N.	JSF++ Definition
128	Comments that document actions or sources (e.g. tables, figures, paragraphs, etc.) outside of the file being documented will not be allowed.
129	Comments in header files should describe the externally visible behavior of the functions or classes being documented.
130	The purpose of every line of executable code should be explained by a comment, although one comment may describe more than one line of code.
131	One should avoid stating in comments what is better stated in code (i.e. do not simply repeat what is in the code).
132	Each variable declaration, typedef, enumeration value, and structure member will be commented.
134	Assumptions (limitations) made by functions should be documented in the function’s preamble.

Initialization

N.	JSF++ Definition
143	Variables will not be introduced until they can be initialized with meaningful values. (See also AV Rule 136, AV Rule 142, and AV Rule 73 concerning declaration scope, initialization before use, and default constructors respectively.)

Types

N.	JSF++ Definition
146	Floating point implementations shall comply with a defined floating point standard. The standard that will be used is the ANSI^®/IEEE^® Std 754 [1].

Unions and Bit Fields

N.	JSF++ Definition
155	Bit-fields will not be used to pack data into a word for the sole purpose of saving space.

Operators

N.	JSF++ Definition
167	The implementation of integer division in the chosen compiler shall be determined, documented and taken into account.

Type Conversions

N.	JSF++ Definition
183	Every possible measure should be taken to avoid type casting.

Expressions

N.	JSF++ Definition
204	A single operation with side-effects shall only be used in the following contexts: by itself the right-hand side of an assignment a condition the only argument expression with a side-effect in a function call condition of a loop switch condition single part of a chained operation

Memory Allocation

N.	JSF++ Definition
207	Unencapsulated global data will be avoided.

Portable Code

N.	JSF++ Definition
210	Algorithms shall not make assumptions concerning how data is represented in memory (e.g. big endian vs. little endian, base class subobject ordering in derived classes, nonstatic data member ordering across access specifiers, etc.).
210.1	Algorithms shall not make assumptions concerning the order of allocation of nonstatic data members separated by an access specifier.
211	Algorithms shall not assume that shorts, ints, longs, floats, doubles or long doubles begin at particular addresses.
212	Underflow or overflow functioning shall not be depended on in any special way.
214	Assuming that non-local static objects, in separate translation units, are initialized in a special order shall not be done.

Efficiency Considerations

N.	JSF++ Definition
216	Programmers should not attempt to prematurely optimize code.

Miscellaneous

N.	JSF++ Definition
217	Compile-time and link-time errors should be preferred over run-time errors.
218	Compiler warning levels will be set in compliance with project policies.

Testing

N.	JSF++ Definition
219	All tests applied to a base class interface shall be applied to all derived class interfaces as well. If the derived class poses stronger postconditions/invariants, then the new postconditions /invariants shall be substituted in the derived class tests.
220	Structural coverage algorithms shall be applied against flattened classes.
221	Structural coverage of a class within an inheritance hierarchy containing virtual functions shall include testing every possible resolution for each set of identical polymorphic references.