DATASHEET
Joint Strike Fighter (JSF) C++ Coding Standards 2005
ENFORCEMENT FOR KW 2024.2
Total | ||
|---|---|---|
a | Total Number of Rules | 233 |
b | Total Number of ‘Not Statically Enforceable’ Rules (Assisted/Unassisted) | 29 |
c | Total Number of Enforceable Rules (a-b) | 204 |
d | Total Number of Enforced Rules | 139 |
e | Total Number of Unenforced Rules | 65 |
f | Enforce Rules Percentage (d/c) | 68% |
g | Unenforced Rules Percentage (e/c) | 32% |
Rule ID | Description | Category | Enforced |
|---|---|---|---|
AV Rule 1 | Any one function (or method) will contain no more than 200 logical source lines of code (L-SLOCs). | Will | Yes – via JSF metrics file |
AV Rule 2 | There shall not be any self-modifying code. | Shall | NSE |
AV Rule 3 | All functions shall have a cyclomatic complexity number of 20 or less. | Shall | Yes -– via JSF metrics file |
AV Rule 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). | Should | NSE |
AV Rule 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). | Shall | NSE |
AV Rule 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. | Shall | NSE |
AV Rule 7 | Approval will not be required for a deviation from a "shall" or "will" Rule that complies with an exception specified by that Rule . | Will | NSE |
AV Rule 8 | All code shall conform to ISO/IEC 14882:2002(E) standard C++. [10] | Shall | No |
AV Rule 9 | Only those characters specified in the C++ basic source character set will be used. | Will | No |
AV Rule 10 | Values of character types will be restricted to a defined and documented subset of ISO 10646-1. [9] | Will | No |
AV Rule 11 | Trigraphs will not be used. | Will | Yes |
AV Rule 12 | The following digraphs will not be used: '<%', '%>', '<:', ':>', '%:', '%:%:'. | Will | Yes |
AV Rule 13 | Multi-byte characters and wide string literals will not be used. | Will | Yes |
AV Rule 14 | Literal suffixes shall use uppercase rather than lowercase letters. | Shall | Yes |
AV Rule 15 | Provision shall be made for run-time checking (defensive programming). | Shall | NSE |
AV Rule 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 [13]. | Shall | No |
AV Rule 17 | The error indicator errno shall not be used. | Shall | Yes |
AV Rule 18 | The macro offsetof, in library | Shall | Yes |
AV Rule 19 | Shall | Yes | |
AV Rule 20 | The setjmp macro and the longjmp function shall not be used. | Shall | Yes |
AV Rule 21 | The signal handling facilities of | Shall | Yes |
AV Rule 22 | The input/output library | Shall | Yes |
AV Rule 23 | The library functions atof, atoi and atol from library | Shall | Yes |
AV Rule 24 | The library functions abort, exit, getenv and system from library | Shall | Yes |
AV Rule 25 | The time handling functions of library | Shall | Yes |
AV Rule 26 | Only the following pre-processor directives shall be used: - #ifndef - #define - #endif - #include | Shall | Yes |
AV Rule 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. | Will | Yes |
AV Rule 28 | The #ifndef and #endif pre-processor directives will only be used as defined in AV Rule 27 to prevent multiple inclusions of the same header file. | Will | Yes |
AV Rule 29 | The #define pre-processor directive shall not be used to create inline macros. Inline functions shall be used instead. | Shall | Yes |
AV Rule 30 | The #define pre-processor directive shall not be used to define constant values. Instead, the const qualifier shall be applied to variable declarations to specify constant values. | Shall | Yes |
AV Rule 31 | The #define pre-processor directive will only be used as part of the technique to prevent multiple inclusions of the same header file. | Will | Yes |
AV Rule 32 | The #include pre-processor directive will only be used to include header (*.h) files. | Will | Yes |
AV Rule 33 | The #include directive shall use the | Shall | Yes |
AV Rule 34 | Header files should contain logically related declarations only. | Should | NSE |
AV Rule 35 | A header file will contain a mechanism that prevents multiple inclusions of itself. | Will | Yes |
AV Rule 36 | Compilation dependencies should be minimized when possible. | Should | Yes |
AV Rule 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. | Should | Yes |
AV Rule 38 | Declarations of classes that are only accessed via pointers (*) or references (&) should be supplied by forward headers that contain only forward declarations. | Should | No |
AV Rule 39 | Header files (*.h) will not contain non-const variable definitions or function definitions. | Will | Yes |
AV Rule 40 | Every implementation file shall include the header files that uniquely define the inline functions, types, and templates used. | Shall | Yes |
AV Rule 41 | Source lines will be kept to a length of 120 characters or less. | Will | No |
AV Rule 42 | Each expression-statement will be on a separate line. | Will | Yes |
AV Rule 43 | Tabs should be avoided. | Should | No |
AV Rule 44 | All indentations will be at least two spaces and be consistent within the same source file. | Will | No |
AV Rule 45 | All words in an identifier will be separated by the '_' character. | Will | NSE |
AV Rule 46 | User-specified identifiers (internal and external) will not rely on significance of more than 64 characters. | Will | Yes |
AV Rule 47 | Identifiers will not begin with the underscore character '_'. | Will | No |
AV Rule 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'. | Will | No |
AV Rule 49 | All acronyms in an identifier will be composed of uppercase letters. | Will | NSE |
AV Rule 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. | Will | No |
AV Rule 51 | All letters contained in function and variable names will be composed entirely of lowercase letters. | Will | No |
AV Rule 52 | Identifiers for constant and enumerator values shall be lowercase. | Shall | No |
AV Rule 53 | Header files will always have a file name extension of ".h". | Will | No |
AV Rule 53.1 | The following character sequences shall not appear in header file names: ', \, /*, //, or ". | Shall | Yes |
AV Rule 54 | Implementation files will always have a file name extension of ".cpp". | Will | No |
AV Rule 55 | The name of a header file should reflect the logical entity for which it provides declarations. | Should | NSE |
AV Rule 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.) | Should | No |
AV Rule 57 | The public, protected, and private sections of a class will be declared in that order (the public section is declared before the protected section which is declared before the private section). | Will | Yes |
AV Rule 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). | Will | No |
AV Rule 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. | Shall | Yes |
AV Rule 60 | Braces ("{}") which enclose a block will be placed in the same column, on separate lines directly before and after the block. | Will | No |
AV Rule 61 | Braces ("{}") which enclose a block will have nothing else on the line except comments (if necessary). | Will | No |
AV Rule 62 | The dereference operator '*' and the address-of operator '&' will be directly connected with the type-specifier. | Will | No |
AV Rule 63 | Spaces will not be used around '.' or '->', nor between unary operators and operands. | Will | No |
AV Rule 64 | A class interface should be complete and minimal. | Should | NSE |
AV Rule 65 | A structure should be used to model an entity that does not require an invariant. | Should | No |
AV Rule 66 | A class should be used to model an entity that maintains an invariant. | Should | No |
AV Rule 67 | Public and protected data should only be used in structs - not classes. | Should | Yes |
AV Rule 68 | Unneeded implicitly generated member functions shall be explicitly disallowed. | Shall | No |
AV Rule 69 | A member function that does not affect the state of an object (its instance variables) will be declared const. | Will | Yes |
AV Rule 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. | Will | Yes |
AV Rule 70.1 | An object shall not be improperly used before its lifetime begins or after its lifetime ends. | Shall | Yes |
AV Rule 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. | Shall | Yes |
AV Rule 71.1 | A class's virtual functions shall not be invoked from its destructor or any of its constructors. | Shall | Yes |
AV Rule 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. | Should | No |
AV Rule 73 | Unnecessary default constructors shall not be defined | Shall | No |
AV Rule 74 | Initialization of nonstatic class members will be performed through the member initialization list rather than through assignment in the body of a constructor. | Will | Yes |
AV Rule 75 | Members of the initialization list shall be listed in the order in which they are declared in the class. | Shall | Yes |
AV Rule 76 | A copy constructor and an assignment operator shall be declared for classes that contain pointers to data items or nontrivial destructors. | Shall | Yes |
AV Rule 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). | Shall | Yes |
AV Rule 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. | Shall | Yes |
AV Rule 78 | All base classes with a virtual function shall define a virtual destructor. | Shall | Yes |
AV Rule 79 | All resources acquired by a class shall be released by the class's destructor. | Shall | Yes |
AV Rule 80 | The default copy and assignment operators will be used for classes when those operators offer reasonable semantics. | Will | No |
AV Rule 81 | The assignment operator shall handle self-assignment correctly. | Shall | Yes |
AV Rule 82 | An assignment operator shall return a reference to *this. | Shall | Yes |
AV Rule 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). | Shall | No |
AV Rule 84 | Operator overloading will be used sparingly and in a conventional manner. | Will | Yes |
AV Rule 85 | When two operators are opposites (such as == and !=), both will be defined and one will be defined in terms of the other. | Will | Yes |
AV Rule 86 | Concrete types should be used to represent simple independent concepts. | Should | NSE |
AV Rule 87 | Hierarchies should be based on abstract classes. | Should | Yes |
AV Rule 88 | Multiple inheritance shall only be allowed in the following restricted form: n interfaces plus m private implementations, plus at most one protected implementation. | Shall | Yes |
AV Rule 88.1 | A stateful virtual base shall be explicitly declared in each derived class that accesses it. | Shall | No |
AV Rule 89 | base class shall not be both virtual and non-virtual in the same hierarchy. | Shall | Yes |
AV Rule 90 | Heavily used interfaces should be minimal, general and abstract. | Should | NSE |
AV Rule 91 | Public inheritance will be used to implement "is-a" relationships. | Will | No |
AV Rule 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. | Will | NSE |
AV Rule 93 | has-a or "is-implemented-in-terms-of" relationships will be modeled through membership or non-public inheritance. | Will | No |
AV Rule 94 | An inherited nonvirtual function shall not be redefined in a derived class. | Shall | Yes |
AV Rule 95 | An inherited default parameter shall never be redefined. | Shall | Yes |
AV Rule 96 | Arrays shall not be treated polymorphically. | Shall | Yes |
AV Rule 97 | Arrays shall not be used in interfaces. Instead, the Array class should be used. | Shall | Yes |
AV Rule 97.1 | Neither operand of an equality operator (== or !=) shall be a pointer to a virtual member function. | Shall | No |
AV Rule 98 | Every nonlocal name, except main(), should be placed in some namespace. | Should | Yes |
AV Rule 99 | amespaces will not be nested more than two levels deep. | Will | No |
AV Rule 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 | Should | No |
AV Rule 101 | Templates shall be reviewed as follows: 1. with respect to the template in isolation considering assumptions or requirements placed on its arguments. 2. with respect to all functions instantiated by actual arguments. | Shall | NSE |
AV Rule 102 | Template tests shall be created to cover all actual template instantiations. | Shall | NSE |
AV Rule 103 | Constraint checks should be applied to template arguments. | Should | No |
AV Rule 104 | A template specialization shall be declared before its use. | Shall | No |
AV Rule 105 | A template definition's dependence on its instantiation contexts should be minimized. | Should | No |
AV Rule 106 | Specializations for pointer types should be made where appropriate. | Should | No |
AV Rule 107 | Functions shall always be declared at file scope. | Shall | Yes |
AV Rule 108 | Functions with variable numbers of arguments shall not be used. | Shall | Yes |
AV Rule 109 | A function definition should not be placed in a class specification unless the function is intended to be inlined. | Should | Yes |
AV Rule 110 | Functions with more than 7 arguments will not be used. | Will | Yes |
AV Rule 111 | A function shall not return a pointer or reference to a non-static local object. | Shall | Yes |
AV Rule 112 | Function return values should not obscure resource ownership. | Should | Yes |
AV Rule 113 | Functions will have a single exit point. | Will | Yes |
AV Rule 114 | All exit points of value-returning functions shall be through return statements. | Shall | Yes |
AV Rule 115 | If a function returns error information, then that error information will be tested. | Will | Yes |
AV Rule 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. | Should | No |
AV Rule 117 | Arguments should be passed by reference if NULL values are not possible. | Should | No |
AV Rule 117.1 | An object should be passed as const T& if the function should not change the value of the object | Should | Yes |
AV Rule 117.2 | An object should be passed as T& if the function may change the value of the object. | Should | No |
AV Rule 118 | Arguments should be passed via pointers if NULL values are possible. | Should | No |
AV Rule 118.1 | An object should be passed as const T* if its value should not be modified. | Should | Yes |
AV Rule 118.2 | An object should be passed as T* if its value may be modified. | Should | No |
AV Rule 119 | Functions shall not call themselves, either directly or indirectly (i.e. recursion shall not be allowed). | Shall | Yes |
AV Rule 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. | Should | NSE |
AV Rule 121 | Only functions with 1 or 2 statements should be considered candidates for inline functions. | Should | No |
AV Rule 122 | Trivial accessor and mutator functions should be inlined. | Should | No |
AV Rule 123 | The number of accessor and mutator functions should be minimized. | Should | No |
AV Rule 124 | Trivial forwarding functions should be inlined. | Should | No |
AV Rule 125 | Unnecessary temporary objects should be avoided. | Should | No |
AV Rule 126 | Only valid C++ style comments (//) shall be used. | Shall | No |
AV Rule 127 | Code that is not used (commented out) shall be deleted. | Shall | No |
AV Rule 128 | Comments that document actions or sources (e.g. tables, figures, paragraphs, etc.) outside of the file being documented will not be allowed. | Will | NSE |
AV Rule 129 | Comments in header files should describe the externally visible behavior of the functions or classes being documented. | Should | NSE |
AV Rule 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. | Should | No |
AV Rule 131 | One should avoid stating in comments what is better stated in code (i.e. do not simply repeat what is in the code). | Should | NSE |
AV Rule 132 | Each variable declaration, typedef, enumeration value, and structure member will be commented. | Will | No |
AV Rule 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). | Will | No |
AV Rule 134 | Assumptions (limitations) made by functions should be documented in the function's preamble. | Should | NSE |
AV Rule 135 | Identifiers in an inner scope shall not use the same name as an identifier in an outer scope, and therefore hide that identifier. | Shall | Yes |
AV Rule 136 | Declarations should be at the smallest feasible scope. (See also AV Rule 143). | Should | Yes |
AV Rule 137 | All declarations at file scope should be static where possible. | Should | No |
AV Rule 138 | dentifiers shall not simultaneously have both internal and external linkage in the same translation unit. | Shall | Yes |
AV Rule 139 | External objects will not be declared in more than one file. | Will | No |
AV Rule 140 | The register storage class specifier shall not be used. | Shall | Yes |
AV Rule 141 | A class, structure, or enumeration will not be declared in the definition of its type. | Will | Yes |
AV Rule 142 | All variables shall be initialized before use. | Shall | Yes |
AV Rule 143 | Variables will not be introduced until they can be initialized with meaningful values. | Will | No |
AV Rule 144 | Braces shall be used to indicate and match the structure in the non-zero initialization of arrays and structures. | Shall | Yes |
AV Rule 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. | Shall | Yes |
AV Rule 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]. | Shall | NSE |
AV Rule 147 | The underlying bit representations of floating point numbers shall not be used in any way by the programmer. | Shall | Yes |
AV Rule 148 | Enumeration types shall be used instead of integer types (and constants) to select from a limited series of choices. | Shall | No |
AV Rule 149 | Octal constants (other than zero) shall not be used. | Shall | Yes |
AV Rule 150 | Hexadecimal constants will be represented using all uppercase letters. | Will | Yes |
AV Rule 151 | Numeric values in code will not be used; symbolic values will be used instead. | Will | No |
AV Rule 151.1 | A string literal shall not be modified. | Shall | Yes |
AV Rule 152 | Multiple variable declarations shall not be allowed on the same line. | Shall | Yes |
AV Rule 153 | Unions shall not be used. | Shall | Yes |
AV Rule 154 | Bit-fields shall have explicitly unsigned integral or enumeration types only. | Shall | Yes |
AV Rule 155 | Bit-fields will not be used to pack data into a word for the sole purpose of saving space. | Will | No |
AV Rule 156 | All the members of a structure (or class) shall be named and shall only be accessed via their names. | Shall | Yes |
AV Rule 157 | The right hand operand of a && or || operator shall not contain side effects. | Shall | Yes |
AV Rule 158 | The operands of a logical && or || shall be parenthesized if the operands contain binary operators. | Shall | Yes |
AV Rule 159 | Operators ||, &&, and unary & shall not be overloaded. | Shall | Yes |
AV Rule 160 | An assignment expression shall be used only as the expression in an expression statement. | Shall | Yes |
AV Rule 162 | Signed and unsigned values shall not be mixed in arithmetic or comparison operations. | Shall | Yes |
AV Rule 163 | Unsigned arithmetic shall not be used. | Shall | No |
AV Rule 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). | Shall | Yes |
AV Rule 164.1 | The left-hand operand of a right-shift operator shall not have a negative value. | Shall | Yes |
AV Rule 165 | The unary minus operator shall not be applied to an unsigned expression. | Shall | Yes |
AV Rule 166 | The sizeof operator will not be used on expressions that contain side effects. | Will | Yes |
AV Rule 167 | The implementation of integer division in the chosen compiler shall be determined, documented and taken into account. | Shall | NSE |
AV Rule 168 | The comma operator shall not be used. | Shall | Yes |
AV Rule 169 | Pointers to pointers should be avoided when possible. | Should | Yes |
AV Rule 170 | More than 2 levels of pointer indirection shall not be used. | Shall | Yes |
AV Rule 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). | Shall | No |
AV Rule 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. | Shall | Yes |
AV Rule 174 | The null pointer shall not be de-referenced. | Shall | Yes |
AV Rule 175 | A pointer shall not be compared to NULL or be assigned NULL; use plain 0 instead. | Shall | Yes |
AV Rule 176 | A typedef will be used to simplify program syntax when declaring function pointers. | Will | No |
AV Rule 177 | User-defined conversion functions should be avoided. | Should | Yes |
AV Rule 178 | Down casting (casting from base to derived class) shall only be allowed through one of the following mechanisms: - 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) | Shall | Yes |
AV Rule 179 | A pointer to a virtual base class shall not be converted to a pointer to a derived class. | Shall | Yes |
AV Rule 180 | Implicit conversions that may result in a loss of information shall not be used. | Shall | Yes |
AV Rule 181 | Redundant explicit casts will not be used. | Will | No |
AV Rule 182 | Type casting from any type to or from pointers shall not be used. | Shall | Yes |
AV Rule 183 | Every possible measure should be taken to avoid type casting. | Should | No |
AV Rule 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. | Shall | Yes |
AV Rule 185 | C++ style casts (const_cast, reinterpret_cast, and static_cast) shall be used instead of the traditional C-style casts | Shall | Yes |
AV Rule 186 | There shall be no unreachable code. | Shall | Yes |
AV Rule 187 | All non-null statements shall potentially have a side-effect. | Shall | Yes |
AV Rule 188 | Labels will not be used, except in switch statements. | Will | Yes |
AV Rule 189 | The goto statement shall not be used. | Shall | Yes |
AV Rule 190 | The continue statement shall not be used. | Shall | Yes |
AV Rule 191 | The break statement shall not be used (except to terminate the cases of a switch statement). | Shall | Yes |
AV Rule 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. | Will | Yes |
AV Rule 193 | Every non-empty case clause in a switch statement shall be terminated with a break statement. | Shall | Yes |
AV Rule 194 | All switch statements that do not intend to test for every enumeration value shall contain a final default clause. | Shall | Yes |
AV Rule 195 | A switch expression will not represent a Boolean value. | Will | Yes |
AV Rule 196 | Every switch statement will have at least two cases and a potential default. | Will | Yes |
AV Rule 197 | Floating point variables shall not be used as loop counters. | Shall | Yes |
AV Rule 198 | The initialization expression in a for loop will perform no actions other than to initialize the value of a single for loop parameter. | Will | Yes |
AV Rule 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. | Will | Yes |
AV Rule 200 | Null initialize or increment expressions in for loops will not be used; a while loop will be used instead. | Will | Yes |
AV Rule 201 | Numeric variables being used within a for loop for iteration counting shall not be modified in the body of the loop. | Shall | Yes |
AV Rule 202 | Floating point variables shall not be tested for exact equality or inequality. | Shall | Yes |
AV Rule 203 | Evaluation of expressions shall not lead to overflow/underflow (unless required algorithmically and then should be heavily documented). | Shall | Yes |
AV Rule 204 | single operation with side-effects will 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. | Shall | Yes |
AV Rule 204.1 | he value of an expression shall be the same under any order of evaluation that the standard permits. | Shall | Yes |
AV Rule 205 | The volatile keyword shall not be used unless directly interfacing with hardware. | Shall | Yes |
AV Rule 206 | Allocation/deallocation from/to the free store (heap) shall not occur after initialization. | Shall | Yes |
AV Rule 207 | Unencapsulated global data will be avoided. | Will | Yes |
AV Rule 208 | C++ exceptions shall not be used (i.e. throw, catch and try shall not be used.) | Shall | Yes |
AV Rule 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. | Shall | Yes |
AV Rule 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. | Shall | Yes |
AV Rule 210.1 | lgorithms shall not make assumptions concerning the order of allocation of nonstatic data members separated by an access specifier. See also AV Rule 210 on data representation. | Shall | Yes |
AV Rule 211 | Algorithms shall not assume that shorts, ints, longs, floats, doubles or long doubles begin at particular addresses. | Shall | NSE |
AV Rule 212 | Underflow or overflow functioning shall not be depended on in any special way. | Shall | Yes |
AV Rule 213 | No dependence shall be placed on C++'s operator precedence Rule s, below arithmetic operators, in expressions. | Shall | Yes |
AV Rule 214 | Assuming that non-local static objects, in separate translation units, are initialized in a special order shall not be done. | Shall | Yes |
AV Rule 215 | Pointer arithmetic will not be used. | Will | Yes |
AV Rule 216 | Programmers should not attempt to prematurely optimize code. | Should | NSE |
AV Rule 217 | Compile-time and link-time errors should be preferred over run-time errors. | Should | No |
AV Rule 218 | Compiler warning levels will be set in compliance with project policies. | Will | NSE |
AV Rule 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. | Shall | NSE |
AV Rule 220 | Structural coverage algorithms shall be applied against flattened classes. | Shall | NSE |
AV Rule 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. | Shall | NSE |