ほとんどのルールは、静的解析によって自動的に強制可能です。
部分的に強制可能なもの、あるいは強制不可能なものもあり、これらは手動のコードレビューによって強制する必要があります。これらは☑でマークされています。
ほとんどのルールは、コードの書き方に関する典型的なコーディングガイドラインです。ただし、MISRA C+++:2008に比べて一部のルールが緩和されているため（例：例外および動的メモリの使用が許可されている）、コンパイラツールチェーンおよびプロセスに関連するルールや、分析またはテストに関するものも含まれています。これらのルールはドキュメンテーションのために含まれ、⚯でマークされています。
最後に、いくつかのルールでは、Imagix 4Dの表示および解析ツールを使用して、これらの状況が発生する場所を特定するようユーザーに要求します。これらのルールは⚙でマークされています。
The word AUTOSAR and the AUTOSAR logo are registered trademarks. "MISRA" is a registered trademark owned by HORIBA MIRA Ltd, held on behalf of the MISRA Consortium.
| Rule M0-1-1 | | A project shall not contain unreachable code. |
| Rule M0-1-2 | | A project shall not contain infeasible paths. |
| Rule M0-1-3 | | A project shall not contain unused variables. |
| Rule M0-1-4 | | A project shall not contain non-volatile POD variables having only one use. |
| Rule A0-1-1 | ☑ | A project shall not contain instances of non-volatile variables being given values that are never subsequently used. |
| Rule A0-1-2 | | The value returned by a function having a non-void return type that is not an overloaded operator shall always be used. |
| Rule M0-1-8 | ☑ | All functions with void return type shall have external side effect(s). |
| Rule M0-1-9 | ☑ | There shall be no dead code. |
| Rule M0-1-10 | ☑ | Every defined function shall be called at least once. |
| Rule A0-1-3 | ☑ | Every function defined in an anonymous namespace, or static function with internal linkage, or private member function shall be used. |
| Rule A0-1-4 | | There shall be no unused named parameters in non-virtual functions. |
| Rule A0-1-5 | | There shall be no unused named parameters in the set of parameters for a virtual function and all the functions that override it. |
| Rule A0-1-6 | | There should be no unused type declarations. |
| Rule M0-2-1 | ☑ | An object shall not be assigned to an overlapping object. |
| Rule M0-3-1 | ⚯ | Minimization of run-time failures shall be ensured. |
| Rule M0-3-2 | | If a function generates error information, then that error information shall be tested. |
| Rule M0-4-1 | ⚯ | Use of scaled-integer or fixed-point arithmetic shall be documented. |
| Rule M0-4-2 | ⚯ | Use of floating-point shall be documented. |
| Rule A0-4-1 | ⚯ | Floating-point implementation shall comply with IEEE 754 standard. |
| Rule A0-4-2 | | Type long double shall not be used. |
| Rule A0-4-3 | ⚯ | The implementations in the chosen compiler shall strictly comply with the C++14 Language Standard. |
| Rule A0-4-4 | ☑ | Range, domain and pole errors shall be checked when using math functions. |
| Rule A1-1-1 | | All code shall conform to ISO/IEC 14882:2014 - Programming Language C++ and shall not use deprecated features. |
| Rule M1-0-2 | ⚯ | Multiple compilers shall only be used if they have a common, defined interface. |
| Rule A1-1-2 | ⚯ | A warning level of the compilation process shall be set in compliance with project policies. |
| Rule A1-1-3 | ⚯ | An optimization option that disregards strict standard compliance shall not be turned on in the chosen compiler. |
| Rule A1-2-1 | ⚯ | Tool confidence level of the chosen compiler. |
| Rule A1-4-1 | ⚯ | Code metrics. |
| Rule A1-4-3 | ⚯ | All code should compile free of compiler warnings. |
| Rule A2-3-1 | | Only those characters specified in the C++ Language Standard basic source character set shall be used in the source code. |
| Rule A2-5-1 | | Trigraphs shall not be used. |
| Rule A2-5-2 | | Digraphs should not be used. |
| Rule M2-7-1 | | The character sequence /* shall not be used within a C-style comment. |
| Rule A2-7-2 | ☑ | Sections of code shall not be "commented out". |
| Rule A2-7-3 | | All declarations of "user-defined" types, data members, functions and methods shall be preceded by documentation. |
| Rule A2-7-4 | | The character \ shall not occur as a last character of a C++ comment. |
| Rule A2-7-5 | ⚯ | Comments shall not document any actions or sources that are outside of the file. |
| Rule A2-8-1 | ⚯ | A header file name should reflect the logical entity for which it provides declarations. |
| Rule A2-8-2 | ⚯ | An implementation file name should reflect the logical entity for which it provides definitions. |
| Rule M2-10-1 | | Different identifiers shall be typographically unambiguous. |
| Rule A2-10-1 | | An Identifier declared in an inner scope shall not hide an identifier declared in an outer scope. |
| Rule A2-10-4 | | The identifier name of a non-member object with static storage duration or static function shall not be reused within a namespace. |
| Rule A2-10-5 | | An identifier name of a function with static storage duration or a non-member object with external or internal linkage should not be reused. |
| Rule A2-10-6 | | A class or enumeration name shall not be hidden by a variable, function or enumerator declaration in the same scope. |
| Rule A2-11-1 | | Volatile keyword shall not be used. |
| Rule A2-13-1 | | Only those escape sequences that are defined in ISO/IEC 14882:2014 shall be used. |
| Rule A2-13-5 | | Hexadecimal constants should be upper case. |
| Rule A2-13-6 | | Universal character names shall be used only inside character or string literals. |
| Rule M2-13-2 | | Octal constants (other than zero) and octal escape sequences (other than "\0") shall not be used. |
| Rule M2-13-3 | | A "U" suffix shall be applied to all octal or hexadecimal integer literals of unsigned type. |
| Rule M2-13-4 | | Literal suffixes shall be upper case. |
| Rule A2-13-2 | | String literals with different encoding prefixes shall not be concatenated. |
| Rule A2-13-3 | | Type wchar_t shall not be used. |
| Rule A2-13-4 | | String literals shall not be assigned to non-constant pointers. |
| Rule A3-1-1 | | It shall be possible to include any header file in multiple translation units without violating the One Definition Rule. |
| Rule A3-1-2 | | Header files, that are defined locally in the project, shall have a file name extension of one of: ".h", ".hpp" or ".hxx". |
| Rule A3-1-3 | | Implementation files, that are defined locally in the project, should have a file name extension of ".cpp". |
| Rule M3-1-2 | | Functions shall not be declared at block scope. |
| Rule A3-1-4 | | When an array with external linkage is declared, its size shall be stated explicitly. |
| Rule A3-1-5 | | Function definition placement in class definition. |
| Rule A3-1-6 | | Trivial accessor and mutator functions should be inlined. |
| Rule M3-2-1 | | All declarations of an object or function shall have compatible types. |
| Rule M3-2-2 | | The One Definition Rule shall not be violated. |
| Rule M3-2-3 | | A type, object or function that is used in multiple translation units shall be declared in one and only one file. |
| Rule M3-2-4 | | An identifier with external linkage shall have exactly one definition. |
| Rule A3-3-1 | | Objects or functions with external linkage shall be declared in a header file. |
| Rule A3-3-2 | | Static and thread-local objects shall be constant-initialized. |
| Rule M3-3-2 | | If a function has internal linkage then all re-declarations shall include the static storage class specifier. |
| Rule M3-4-1 | | An identifier declared to be an object or type shall be defined in a block that minimizes its visibility. |
| Rule A3-8-1 | ⚙ | An object shall not be accessed outside of its lifetime. |
| Rule M3-9-1 | | The types used for an object, a function return type, or a function parameter shall be token-for-token identical in all declarations and re-declarations. |
| Rule A3-9-1 | | Fixed width integer types from , indicating the size and signedness, shall be used in place of the basic numerical types. |
| Rule M3-9-3 | | The underlying bit representations of floating-point values shall not be used. |
| Rule M4-5-1 | | Expressions with type bool shall not be used as operands to certain built-in operators. |
| Rule A4-5-1 | | Expressions with type enum or enum class shall not be used as operands to built-in and overloaded operators. |
| Rule M4-5-3 | | Expressions with type (plain) char and wchar_t shall not be used as operands to certain built-in operators. |
| Rule A4-7-1 | | An integer expression shall not lead to data loss. |
| Rule M4-10-1 | | NULL shall not be used as an integer value. |
| Rule A4-10-1 | | Only nullptr literal shall be used as the null-pointer-constant. |
| Rule M4-10-2 | | Literal zero (0) shall not be used as the null-pointer-constant. |
| Rule A5-0-1 | ☑ | The value of an expression shall be the same under any order of evaluation that the standard permits. |
| Rule M5-0-2 | | Limited dependence should be placed on C++ operator precedence rules in expressions. |
| Rule M5-0-3 | | A cvalue expression shall not be implicitly converted to a different underlying type. |
| Rule M5-0-4 | | An implicit integral conversion shall not change the signedness of the underlying type. |
| Rule M5-0-5 | | There shall be no implicit floating-integral conversions. |
| Rule M5-0-6 | | An implicit integral or floating-point conversion shall not reduce the size of the underlying type. |
| Rule M5-0-7 | | There shall be no explicit floating-integral conversions of a cvalue expression. |
| Rule M5-0-8 | | An explicit integral or floating-point conversion shall not increase the size of the underlying type of a cvalue expression. |
| Rule M5-0-9 | | An explicit integral conversion shall not change the signedness of the underlying type of a cvalue expression. |
| Rule M5-0-10 | | If the bitwise operators ~ and << are applied to an operand with an underlying type of unsigned char or unsigned short, the result shall be immediately cast to the underlying type of the operand. |
| Rule M5-0-11 | | The plain char type shall only be used for the storage and use of character values. |
| Rule M5-0-12 | | signed char and unsigned char type shall only be used for the storage and use of numeric values. |
| Rule A5-0-2 | | The condition of an if-statement and the condition of an iteration statement shall have type bool. |
| Rule M5-0-14 | | The first operand of a conditional-operator shall have type bool. |
| Rule M5-0-15 | | Array indexing shall be the only form of pointer arithmetic. |
| Rule M5-0-16 | ☑ | A pointer operand and any pointer resulting from pointer arithmetic using that operand shall both address elements of the same array. |
| Rule M5-0-17 | ☑ | Subtraction between pointers shall only be applied to pointers that address elements of the same array. |
| Rule A5-0-4 | ☑ | Pointer arithmetic shall not be used with pointers to non-final classes. |
| Rule M5-0-18 | ☑ | >, >=, <, <= shall not be applied to objects of pointer type, except where they point to the same array. |
| Rule A5-0-3 | | The declaration of objects shall contain no more than two levels of pointer indirection. |
| Rule M5-0-20 | | Non-constant operands to a binary bitwise operator shall have the same underlying type. |
| Rule M5-0-21 | | Bitwise operators shall only be applied to operands of unsigned underlying type. |
| Rule A5-1-1 | | Literal values shall not be used apart from type initialization, otherwise symbolic names shall be used instead. |
| Rule A5-1-2 | | Variables shall not be implicitly captured in a lambda expression. |
| Rule A5-1-3 | | Parameter list (possibly empty) shall be included in every lambda expression. |
| Rule A5-1-4 | ☑ | A lambda expression object shall not outlive any of its reference-captured objects. |
| Rule A5-1-6 | ☑ | Return type of a non-void return type lambda expression should be explicitly specified. |
| Rule A5-1-7 | | A lambda shall not be an operand to decltype or typeid. |
| Rule A5-1-8 | | Lambda expressions should not be defined inside another lambda expression. |
| Rule A5-1-9 | | Identical unnamed lambda expressions shall be replaced with a named function or a named lambda expression. |
| Rule A5-2-1 | | dynamic_cast should not be used. |
| Rule M5-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. |
| Rule M5-2-3 | | Casts from a base class to a derived class should not be performed on polymorphic types. |
| Rule A5-2-2 | | Traditional C-style casts shall not be used. |
| Rule A5-2-3 | | A cast shall not remove any const or volatile qualification from a pointer or reference. |
| Rule A5-2-4 | | reinterpret_cast shall not be used. |
| Rule A5-2-5 | ⚙ | An array or container shall not be accessed beyond its range. |
| Rule A5-2-6 | | The operands of a logical && or \\ shall be parenthesized if the operands contain binary operators. |
| Rule M5-2-6 | | A cast shall not convert a pointer to a function to any other pointer type, including a pointer to function type. |
| Rule M5-2-8 | | An object with integer type or pointer to void type shall not be converted to an object with pointer type. |
| Rule M5-2-9 | | A cast should not convert a pointer type to an integral type. |
| Rule M5-2-10 | | The increment (++) and decrement (--) operators should not be mixed with other operators in an expression. |
| Rule M5-2-11 | | The comma operator, && operator and the || operator shall not be overloaded. |
| Rule M5-2-12 | | An identifier with array type passed as a function argument shall not decay to a pointer. |
| Rule A5-3-1 | ☑ | Evaluation of the operand to the typeid operator shall not contain side effects. |
| Rule M5-3-1 | | Each operand of the ! operator, the logical && or the logical || operators shall have type bool. |
| Rule A5-3-2 | | Null pointers shall not be dereferenced. |
| Rule A5-3-3 | | Pointers to incomplete class types shall not be deleted. |
| Rule M5-3-2 | | The unary minus operator shall not be applied to an expression whose underlying type is unsigned. |
| Rule M5-3-3 | | The unary & operator shall not be overloaded. |
| Rule M5-3-4 | | Evaluation of the operand to the sizeof operator shall not contain side effects. |
| Rule A5-5-1 | ☑ | A pointer to member shall not access non-existent class members. |
| Rule A5-6-1 | | The right hand operand of the integer division or remainder operators shall not be equal to zero. |
| Rule M5-8-1 | ☑ | The right hand operand of a shift operator shall lie between zero and one less than the width in bits of the underlying type of the left hand operand. |
| Rule A5-10-1 | ☑ | A pointer to member virtual function shall only be tested for equality with null-pointer-constant. |
| Rule M5-14-1 | ☑ | The right hand operand of a logical && or || operator shall not contain side effects. |
| Rule A5-16-1 | ☑ | The ternary conditional operator shall not be used as a sub-expression. |
| Rule M5-17-1 | ☑ | The semantic equivalence between a binary operator and its assignment operator form shall be preserved. |
| Rule M5-18-1 | | The comma operator shall not be used. |
| Rule M5-19-1 | | Evaluation of constant unsigned integer expressions should not lead to wrap-around. |
| Rule M6-2-1 | | Assignment operators shall not be used in sub-expressions. |
| Rule A6-2-1 | | Move and copy assignment operators shall either move or respectively copy base classes and data members of a class, without any side effects. |
| Rule A6-2-2 | | Expression statements shall not be explicit calls to constructors of temporary objects only. |
| Rule M6-2-2 | | Floating-point expressions shall not be directly or indirectly tested for equality or inequality. |
| Rule M6-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. |
| Rule M6-3-1 | | The statement forming the body of a switch, while, do ... while or for statement shall be a compound statement. |
| Rule M6-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. |
| Rule M6-4-2 | | All if ... else if constructs shall be terminated with an else clause. |
| Rule M6-4-3 | | A switch statement shall be a well-formed switch statement. |
| Rule M6-4-4 | | A switch-label shall only be used when the most closely-enclosing compound statement is the body of a switch statement. |
| Rule M6-4-5 | | An unconditional throw or break statement shall terminate every non-empty switch-clause. |
| Rule M6-4-6 | | The final clause of a switch statement shall be the default-clause. |
| Rule M6-4-7 | | The condition of a switch statement shall not have bool type. |
| Rule A6-4-1 | | A switch statement shall have at least two case-clauses, distinct from the default label. |
| Rule A6-5-1 | ☑ | A for-loop that loops through all elements of the container and does not use its loop-counter shall not be used. |
| Rule A6-5-2 | | A for loop shall contain a single loop-counter which shall not have floating-point type. |
| Rule M6-5-2 | | If loop-counter is not modified by -- or ++, then, within condition, the loop-counter shall only be used as an operand to <=, <,> or >=. |
| Rule M6-5-3 | ☑ | The loop-counter shall not be modified within condition or statement. |
| Rule M6-5-4 | | The loop-counter shall be modified by one of --, ++, -=n, or +=n; where n remains constant for the duration of the loop. |
| Rule M6-5-5 | ☑ | A loop-control-variable other than the loop-counter shall not be modified within condition or expression. |
| Rule M6-5-6 | | A loop-control-variable other than the loop-counter which is modified in statement shall have type bool. |
| Rule A6-5-3 | | Do statements should not be used. |
| Rule A6-5-4 | | For-init-statement and expression should not perform actions other than loop-counter initialization and modification. |
| Rule A6-6-1 | | The goto statement shall not be used. |
| Rule M6-6-1 | | Any label referenced by a goto statement shall be declared in the same block, or in a block enclosing the goto statement. |
| Rule M6-6-2 | | The goto statement shall jump to a label declared later in the same function body. |
| Rule M6-6-3 | | The continue statement shall only be used within a well-formed for loop. |
| Rule A7-1-1 | | Constexpr or const specifiers shall be used for immutable data declaration. |
| Rule A7-1-2 | ☑ | The constexpr specifier shall be used for values that can be determined at compile time. |
| Rule M7-1-2 | | A pointer or reference parameter in a function shall be declared as pointer to const or reference to const if the corresponding object is not modified. |
| Rule A7-1-3 | | CV-qualifiers shall be placed on the right hand side of the type that is a typedef or a using name. |
| Rule A7-1-4 | | The register keyword shall not be used. |
| Rule A7-1-5 | | Restictions on use of auto specifier. |
| Rule A7-1-6 | | The typedef specifier shall not be used. |
| Rule A7-1-7 | | Each expression statement and identifier declaration shall be placed on a separate line. |
| Rule A7-1-8 | | A non-type specifier shall be placed before a type specifier in a declaration. |
| Rule A7-1-9 | | A class, structure, or enumeration shall not be declared in the definition of its type. |
| Rule A7-2-1 | ☑ | An expression with enum underlying type shall only have values corresponding to the enumerators of the enumeration. |
| Rule A7-2-2 | | Enumeration underlying base type shall be explicitly defined. |
| Rule A7-2-3 | | Enumerations shall be declared as scoped enum classes. |
| Rule A7-2-4 | | In an enumeration, either (1) none, (2) the first or (3) all enumerators shall be initialized. |
| Rule A7-2-5 | ⚯ | Enumerations should be used to represent sets of related named constants. |
| Rule M7-3-1 | | The global namespace shall only contain main, namespace declarations and extern "C" declarations. |
| Rule M7-3-2 | | The identifier main shall not be used for a function other than the global function main. |
| Rule M7-3-3 | | There shall be no unnamed namespaces in header files. |
| Rule M7-3-4 | | using-directives shall not be used. |
| Rule A7-3-1 | | All overloads of a function shall be visible from where it is called. |
| Rule M7-3-6 | | using-directives and using-declarations (excluding class scope or function scope using-declarations) shall not be used in header files. |
| Rule A7-4-1 | | The asm declaration shall not be used. |
| Rule M7-4-1 | ⚯ | All usage of assembler shall be documented. |
| Rule M7-4-2 | | Assembler instructions shall only be introduced using the asm declaration. |
| Rule M7-4-3 | | Assembly language shall be encapsulated and isolated. |
| Rule M7-5-1 | | A function shall not return a reference or a pointer to an automatic variable (including parameters), defined within the function. |
| Rule M7-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. |
| Rule A7-5-1 | | A function shall not return a reference or a pointer to a parameter that is passed by reference or const reference. |
| Rule A7-5-2 | ☑ | Functions should not call themselves, either directly or indirectly. |
| Rule A7-6-1 | | Functions declared with the [[noreturn]] attribute shall not return. |
| Rule M8-0-1 | | An init-declarator-list or a member-declarator-list shall consist of a single init-declarator or member-declarator respectively. |
| Rule A8-2-1 | | When declaring function templates, the trailing return type syntax shall be used if the return type depends on the type of parameters. |
| Rule M8-3-1 | | Parameters in an overriding virtual function shall either use the same default arguments as the function they override, or else shall not specify any default arguments. |
| Rule A8-4-1 | | Functions shall not be defined using the ellipsis notation. |
| Rule M8-4-2 | | The identifiers used for the parameters in a re-declaration of a function shall be identical to those in the declaration. |
| Rule A8-4-2 | | All exit paths from a function with non-void return type shall have an explicit return statement with an expression. |
| Rule M8-4-4 | | A function identifier shall either be used to call the function or it shall be preceded by a &. |
| Rule A8-4-3 | ☑ | Common ways of passing parameters should be used. |
| Rule A8-4-4 | | Multiple output values from a function should be returned as a struct or tuple. |
| Rule A8-4-5 | | "consume" parameters declared as X && shall always be moved from. |
| Rule A8-4-6 | | "forward" parameters declared as T && shall always be forwarded. |
| Rule A8-4-7 | | "in" parameters for "cheap to copy" types shall be passed by value. |
| Rule A8-4-8 | | Output parameters shall not be used. |
| Rule A8-4-9 | | "in-out" parameters declared as T & shall be modified. |
| Rule A8-4-10 | | A parameter shall be passed by reference if it can't be NULL. |
| Rule A8-4-11 | | A smart pointer shall only be used as a parameter type if it expresses lifetime semantics. |
| Rule A8-4-12 | | std::unique_ptr passed to a function. |
| Rule A8-4-13 | | std::shared_ptr passed to a function. |
| Rule A8-4-14 | ☑ | Interfaces shall be precisely and strongly typed. |
| Rule A8-5-0 | | All memory shall be initialized before it is read. |
| Rule A8-5-1 | | Order of initialization in an initialization list. |
| Rule M8-5-2 | | Braces shall be used to indicate and match the structure in the non-zero initialization of arrays and structures. |
| Rule A8-5-2 | | Braced-initialization {}, without equals sign, shall be used for variable initialization. |
| Rule A8-5-3 | | A variable of type auto shall not be initialized using {} or ={} braced-initialization. |
| Rule A8-5-4 | | User-declared constructor with parameter of type std::initializer_list. |
| Rule M9-3-1 | | const member functions shall not return non-const pointers or references to class-data. |
| Rule A9-3-1 | | Member functions shall not return non-const "raw" pointers or references to private or protected data owned by the class. |
| Rule M9-3-3 | | If a member function can be made static then it shall be made static, otherwise if it can be made const then it shall be made const. |
| Rule A9-5-1 | | Unions shall not be used. |
| Rule M9-6-1 | ⚯ | When the absolute positioning of bits representing a bit-field is required, then the behaviour and packing of bit-fields shall be documented. |
| Rule A9-6-1 | | Data types used for interfacing with hardware or conforming to communication protocols shall be trivial, standard-layout and only contain members of types with defined sizes. |
| Rule A9-6-2 | ⚯ | Bit-fields shall be used only when interfacing to hardware or conforming to communication protocols. |
| Rule M9-6-4 | | Named bit-fields with signed integer type shall have a length of more than one bit. |
| Rule A10-0-1 | ☑ | Public inheritance shall be used to implement "is-a" relationship. |
| Rule A10-0-2 | ☑ | Membership or non-public inheritance shall be used to implement "has-a" relationship. |
| Rule A10-1-1 | | Class shall not be derived from more than one base class which is not an interface class. |
| Rule M10-1-1 | | Classes should not be derived from virtual bases. |
| Rule M10-1-2 | | A base class shall only be declared virtual if it is used in a diamond hierarchy. |
| Rule M10-1-3 | | An accessible base class shall not be both virtual and non-virtual in the same hierarchy. |
| Rule M10-2-1 | | All accessible entity names within a multiple inheritance hierarchy should be unique. |
| Rule A10-2-1 | | Non-virtual public or protected member functions shall not be redefined in derived classes. |
| Rule A10-3-1 | | Virtual function declaration shall contain exactly one of the three specifiers: (1) virtual, (2) override, (3) final. |
| Rule A10-3-2 | | Each overriding virtual function shall be declared with the override or final specifier. |
| Rule A10-3-3 | | Virtual functions shall not be introduced in a final class. |
| Rule A10-3-5 | | A user-defined assignment operator shall not be virtual. |
| Rule M10-3-3 | | A virtual function shall only be overridden by a pure virtual function if it is itself declared as pure virtual. |
| Rule A10-4-1 | ☑ | Hierarchies should be based on interface classes. |
| Rule M11-0-1 | | Member data in non-POD class types shall be private. |
| Rule A11-0-1 | | A non-POD type should be defined as class. |
| Rule A11-0-2 | | Restrictions on struct definitions. |
| Rule A11-3-1 | | Friend declarations shall not be used. |
| Rule A12-0-1 | | Special member functions in classes. |
| Rule A12-0-2 | | Bitwise operations and operations that assume data representation in memory shall not be performed on objects. |
| Rule M12-1-1 | | An object's dynamic type shall not be used from the body of its constructor or destructor. |
| Rule A12-1-1 | | Constructors shall explicitly initialize all virtual base classes, all direct non-virtual base classes and all non-static data members. |
| Rule A12-1-2 | | Both NSDMI and a non-static member initializer in a constructor shall not be used in the same type. |
| Rule A12-1-3 | | Same member constant initializers in contructors. |
| Rule A12-1-4 | | All constructors that are callable with a single argument of fundamental type shall be declared explicit. |
| Rule A12-1-5 | ☑ | Common class initialization for non-constant members shall be done by a delegating constructor. |
| Rule A12-1-6 | | Derived classes that do not need further explicit initialization and require all the constructors from the base class shall use inheriting constructors. |
| Rule A12-4-1 | | Destructor of a base class shall be public virtual, public override or protected non-virtual. |
| Rule A12-4-2 | | If a public destructor of a class is non-virtual, then the class should be declared final. |
| Rule A12-6-1 | | All class data members that are initialized by the constructor shall be initialized using member initializers. |
| Rule A12-7-1 | | Behavior of a user-defined special member function identical to implicitly defined special member function. |
| Rule A12-8-1 | | Move and copy constructors shall move and respectively copy base classes and data members of a class, without any side effects. |
| Rule A12-8-2 | | User-defined copy and move assignment operators should use user-defined no-throw swap function. |
| Rule A12-8-3 | ☑ | Moved-from object shall not be read-accessed. |
| Rule A12-8-4 | | Move constructor shall not initialize its class members and base classes using copy semantics. |
| Rule A12-8-5 | | A copy assignment and a move assignment operators shall handle self-assignment. |
| Rule A12-8-6 | | Copy and move constructors and copy assignment and move assignment operators shall be declared protected or defined "=delete" in base class. |
| Rule A12-8-7 | | Assignment operators should be declared with the ref-qualifier &. |
| Rule A13-1-2 | | User defined suffixes of the user defined literal operators shall start with underscore followed by one or more letters. |
| Rule A13-1-3 | | User defined literals operators shall only perform conversion of passed parameters. |
| Rule A13-2-1 | | An assignment operator shall return a reference to "this". |
| Rule A13-2-2 | | A binary arithmetic operator and a bitwise operator shall return a "prvalue". |
| Rule A13-2-3 | | A relational operator shall return a boolean value. |
| Rule A13-3-1 | | A function that contains "forwarding reference" as its argument shall not be overloaded. |
| Rule A13-5-1 | | If "operator[]" is to be overloaded with a non-const version, const version shall also be implemented. |
| Rule A13-5-2 | | All user-defined conversion operators shall be defined explicit. |
| Rule A13-5-3 | | User-defined conversion operators should not be used. |
| Rule A13-5-4 | | If two opposite operators are defined, one shall be defined in terms of the other. |
| Rule A13-5-5 | | Comparison operators shall be non-member functions with identical parameter types and noexcept. |
| Rule A13-6-1 | | Digit sequences separators ' usage. |
| Rule A14-1-1 | ⚙ | A template should check if a specific template argument is suitable for this template. |
| Rule A14-5-1 | ⚙ | A template constructor shall not participate in overload resolution for a single argument of the enclosing class type. |
| Rule A14-5-2 | ⚙ | Class members that are not dependent on template class parameters should be defined in a separate base class. |
| Rule A14-5-3 | ⚙ | A non-member generic operator shall only be declared in a namespace that does not contain class (struct) type, enum type or union type declarations. |
| Rule M14-5-3 | ⚙ | A copy assignment operator shall be declared when there is a template assignment operator with a parameter that is a generic parameter. |
| Rule M14-6-1 | ⚙ | In a class template with a dependent base, any name that may be found in that dependent base shall be referred to using a qualified-id or this-> |
| Rule A14-7-1 | ⚙ | A type used as a template argument shall provide all members that are used by the template. |
| Rule A14-7-2 | ⚙ | Template specialization shall be declared in the same file (1) as the primary template (2) as a user-defined type, for which the specialization is declared. |
| Rule A14-8-2 | ⚙ | Explicit specializations of function templates shall not be used. |
| Rule A15-0-1 | ☑ | A function shall not exit with an exception if it is able to complete its task. |
| Rule A15-0-2 | ⚯ | Basic guarantee for exception safety shall be provided. |
| Rule A15-0-3 | ☑ | Exception safety guarantee of a called function shall be considered. |
| Rule A15-0-4 | ☑ | Unchecked exceptions shall be used to represent errors from which the caller cannot reasonably be expected to recover. |
| Rule A15-0-5 | ☑ | Checked exceptions shall be used to represent errors from which the caller can reasonably be expected to recover. |
| Rule A15-0-6 | ⚯ | Analysis of failure modes of exception handling. |
| Rule A15-0-7 | ⚯ | Exception handling mechanism shall guarantee a deterministic worst-case time execution time. |
| Rule A15-0-8 | ⚯ | A worst-case execution time (WCET) analysis shall be performed to determine maximum execution time constraints of the software, covering in particular the exceptions processing. |
| Rule A15-1-1 | | Only instances of types derived from std::exception should be thrown. |
| Rule A15-1-2 | | An exception object shall not be a pointer. |
| Rule M15-0-3 | | Control shall not be transferred into a try or catch block using a goto or a switch statement. |
| Rule M15-1-1 | ☑ | The assignment-expression of a throw statement shall not itself cause an exception to be thrown. |
| Rule M15-1-2 | | NULL shall not be thrown explicitly. |
| Rule M15-1-3 | | An empty throw (throw;) shall only be used in the compound-statement of a catch handler. |
| Rule A15-1-3 | | All thrown exceptions should be unique. |
| Rule A15-1-4 | ☑ | If a function exits with an exception, then place all objects/resources in valid states. |
| Rule A15-1-5 | ⚯ | Exceptions shall not be thrown across execution boundaries. |
| Rule A15-2-1 | | Constructors that are not noexcept shall not be invoked before program startup. |
| Rule A15-2-2 | ☑ | Behavior of a constructor that is not noexcept and cannot finish object initialization. |
| Rule M15-3-1 | ☑ | Exceptions shall be raised only after start-up and before termination of the program. |
| Rule A15-3-2 | ☑ | If a function throws an exception, it shall be handled when meaningful actions can be taken, otherwise it shall be propagated. |
| Rule A15-3-3 | | Main function and a task main function shall catch at least certain exceptions. |
| Rule A15-3-4 | ☑ | If a function throws an exception, it shall be handled when meaningful actions can be taken, otherwise it shall be propagated. |
| Rule M15-3-3 | | Handlers of a function-try-block implementation of a class constructor or destructor shall not reference non-static members from this class or its bases. |
| Rule M15-3-4 | ☑ | Each exception explicitly thrown in the code shall have a handler of a compatible type in all call paths that could lead to that point. |
| Rule A15-3-5 | | A class type exception shall be caught by reference or const reference. |
| Rule M15-3-6 | | Where multiple handlers are provided in a single try-catch statement or function-try-block for a derived class and some or all of its bases, the handlers shall be ordered most-derived to base class. |
| Rule M15-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. |
| Rule A15-4-1 | | Dynamic exception-specification shall not be used. |
| Rule A15-4-2 | | If a function is declared to be noexcept then it shall not exit with an exception. |
| Rule A15-4-3 | | The noexcept specification of a function shall either be identical across all translation units, or identical or more restrictive between a virtual member function and an overrider. |
| Rule A15-4-4 | | A declaration of non-throwing function shall contain noexcept specification. |
| Rule A15-4-5 | | Checked exceptions that could be thrown from a function shall be specified together with the function declaration and they shall be identical in all function declarations and for all its overriders. |
| Rule A15-5-1 | ☑ | All user-provided class destructors, deallocation functions, move constructors, move assignment operators and swap functions shall not exit with an exception. |
| Rule A15-5-2 | | Program shall not be abruptly terminated. |
| Rule A15-5-3 | | The std::terminate() function shall not be called implicitly. |
| Rule A16-0-1 | | The pre-processor shall only be used for unconditional and conditional file inclusion and include guards. |
| Rule M16-0-1 | | #include directives in a file shall only be preceded by other preprocessor directives or comments. |
| Rule M16-0-2 | | Macros shall only be #define'd or #undef'd in the global namespace. |
| Rule A16-2-2 | | There shall be no unused include directives. |
| Rule A16-2-3 | | An include directive shall be added explicitly for every symbol used in a file. |
| Rule M16-0-5 | | Arguments to a function-like macro shall not contain tokens that look like preprocessing directives. |
| Rule M16-0-6 | | In the definition of a function-like macro, each instance of a parameter shall be enclosed in parentheses, unless it is used as the operand of # or ##. |
| Rule M16-0-7 | | Undefined macro identifiers shall not be used in #if or #elif preprocessor directives, except as operands to the defined operator. |
| Rule M16-0-8 | | If the # token appears as the first token on a line, then it shall be immediately followed by a preprocessing token. |
| Rule M16-1-1 | | The defined preprocessor operator shall only be used in one of the two standard forms. |
| Rule M16-1-2 | | All #else, #elif and #endif preprocessor directives shall reside in the same file as the #if or #ifdef directive to which they are related. |
| Rule M16-2-3 | | Include guards shall be provided. |
| Rule A16-2-1 | | The ', ", /*, //, \ characters shall not occur in a header file name or in #include directive. |
| Rule M16-3-1 | | There shall be at most one occurrence of the # or ## operators in a single macro definition. |
| Rule M16-3-2 | | The # and ## operators should not be used. |
| Rule A16-6-1 | ⚯ | #error directive shall not be used. |
| Rule A16-7-1 | ⚯ | The #pragma directive shall not be used. |
| Rule A17-0-1 | | Reserved identifiers, macros and functions in the C++ standard library shall not be defined, redefined or undefined. |
| Rule M17-0-2 | | The names of standard library macros and objects shall not be reused. |
| Rule M17-0-3 | | The names of standard library functions shall not be overridden. |
| Rule A17-0-2 | ⚯ | All project's code including used libraries and any third-party user code shall conform to the AUTOSAR C++14 Coding Guidelines. |
| Rule M17-0-5 | | The setjmp macro and the longjmp function shall not be used. |
| Rule A17-1-1 | | Use of the C Standard Library shall be encapsulated and isolated. |
| Rule A17-6-1 | | Non-standard entities shall not be added to standard namespaces. |
| Rule A18-0-1 | | The C library facilities shall only be accessed through C++ library headers. |
| Rule A18-0-2 | | The error state of a conversion from string to a numeric value shall be checked. |
| Rule M18-0-3 | | The library functions abort, exit, getenv and system from library shall not be used. |
| Rule M18-0-4 | | The time handling functions of library shall not be used. |
| Rule M18-0-5 | | The unbounded functions of library shall not be used. |
| Rule A18-0-3 | | The library (locale.h) and the setlocale function shall not be used. |
| Rule A18-1-1 | | C-style arrays shall not be used. |
| Rule A18-1-2 | | The std::vector specialization shall not be used. |
| Rule A18-1-3 | | The std::auto_ptr type shall not be used. |
| Rule A18-1-4 | | A pointer pointing to an element of an array of objects shall not be passed to a smart pointer of single object type. |
| Rule A18-1-6 | | All std::hash specializations for user-defined types shall have a noexcept function call operator. |
| Rule M18-2-1 | | The macro offsetof shall not be used. |
| Rule A18-5-1 | | Functions malloc, calloc, realloc and free shall not be used. |
| Rule A18-5-2 | | Non-placement new or delete expressions shall not be used. |
| Rule A18-5-3 | ☑ | The form of the delete expression shall match the form of the new expression used to allocate the memory. |
| Rule A18-5-4 | | If a project has sized or unsized version of operator "delete" globally defined, then both sized and unsized versions shall be defined. |
| Rule A18-5-5 | ⚯ | Criteria for memory management functions. |
| Rule A18-5-6 | ⚯ | An analysis shall be performed to analyze the failure modes of dynamic memory management. |
| Rule A18-5-7 | ⚯ | Non-realtime implementation of dynamic memory management. |
| Rule A18-5-8 | ☑ | Objects that do not outlive a function shall have automatic storage duration. |
| Rule A18-5-9 | ☑ | Custom implementations of dynamic memory allocation and deallocation functions. |
| Rule A18-5-10 | ☑ | Placement new shall be used only with properly aligned pointers to sufficient storage capacity. |
| Rule A18-5-11 | ☑ | "operator new" and "operator delete" shall be defined together. |
| Rule M18-7-1 | | The signal handling facilities of shall not be used. |
| Rule A18-9-1 | | The std::bind shall not be used. |
| Rule A18-9-2 | | Forwarding values to other functions. |
| Rule A18-9-3 | | The std::move shall not be used on objects declared const or const&. |
| Rule A18-9-4 | | An argument to std::forward shall not be subsequently used. |
| Rule M19-3-1 | | The error indicator errno shall not be used. |
| Rule A20-8-1 | | An already-owned pointer value shall not be stored in an unrelated smart pointer. |
| Rule A20-8-2 | | A std::unique_ptr shall be used to represent exclusive ownership. |
| Rule A20-8-3 | | A std::shared_ptr shall be used to represent shared ownership. |
| Rule A20-8-4 | | A std::unique_ptr shall be used over std::shared_ptr if ownership sharing is not required. |
| Rule A20-8-5 | | std::make_unique shall be used to construct objects owned by std::unique_ptr. |
| Rule A20-8-6 | | std::make_shared shall be used to construct objects owned by std::shared_ptr. |
| Rule A20-8-7 | ☑ | A std::weak_ptr shall be used to represent temporary shared ownership. |
| Rule A21-8-1 | | Arguments to character-handling functions shall be representable as an unsigned char. |
| Rule A23-0-1 | | An iterator shall not be implicitly converted to const_iterator. |
| Rule A23-0-2 | ☑ | Elements of a container shall only be accessed via valid references, iterators, and pointers. |
| Rule A25-1-1 | | Non-static data members or captured values of predicate function objects. |
| Rule A25-4-1 | ☑ | Ordering predicates used with associative containers and STL sorting and related algorithms shall adhere to a strict weak ordering relation. |
| Rule A26-5-1 | | Pseudorandom numbers shall not be generated using std::rand(). |
| Rule A26-5-2 | | Random number engines shall not be default-initialized. |
| Rule M27-0-1 | | The stream input/output library shall not be used. |
| Rule A27-0-1 | ⚯ | Inputs from independent components shall be validated. |
| Rule A27-0-2 | ☑ | A C-style string shall guarantee sufficient space for data and the null terminator. |
| Rule A27-0-3 | ☑ | Alternate input and output operations on a file stream shall not be used without an intervening flush or positioning call. |
| Rule A27-0-4 | | C-style strings shall not be used. |
