MISRA - Motor Industry Software Reliability Association MISRA-C:2004, doesn't support C99 121 mandatory and 20 advisory rules.
-
MISRA provides a subset of C programming language which is intended to be suitable for embedded systems.
-
C is particularly weak in "type checking".
-
Operator precedence rules are well defined but very complicated.
-
Many areas of C language which are not completely defined, so behaviour may vary from one compiler to another.
-
C standard, in Annex G, lists 201 issues.
-
C is poor in providing run-time checking. thats why code generated by C tends to be small and efficient.
-
C compiler do not provide run-time checking for such common problems as
- arithmetic exceptions (e.g divide by zero),
- overflow,
- validity of addresses for pointers,
- array bound errors
-
Unspecified => These are language constructs that must compile successfully, but in which compiler writer has some freedom as to what the construct does. Ex: "order of evaluation" (22 such issues in C standard)
-
Undefined => programming errors, for which compiler writer is not obliged to provide error message. Ex: invalid parameters to functions,
-
Implementation-defined => like "unspecified" issues, but compiler writer must take a consistent approach and document it. (76 such issues in C standard)
-
Locale-specific => (6 such issues in C standard)
-
The "bit field" facility in C is one of the most poorly defined parts of the language.
-
The signedness of plain 'char' type is implementation-defined and should not be relied upon.
-
Use of static storage-class specifier will ensure that the identifier is only visible in the file in which it is declared.
-
Integral promotion is a fundamental inconsistency in the C language whereby the small integer types behave differently from long and int types.
-
One unfortunate aspect of C language is that it is not possible to define an integer constant with a char or short type.
| Rule | Description | |
|---|---|---|
| Rule 1.1 | (required) | All code shall conform to ISO 9899:1990 standard. |
| Rule 1.2 | (required) | No reliance shall be placed on undefined or unspecified behaviour. |
| Rule 1.3 | (required) | Multiple compilers and/or languages shall only be used if there is a common defined interface standard for object code to which the languages/compilers/assembers conform. (Ex of issues: stack usage, parameter passing etc) |
| Rule 1.4 | (required) | The compiler/linker shall be checked to ensure that 31 character significance and case sensitivity are supported for external identifiers. |
| Rule 1.5 | (advisory) | Floating-point implementations should comply with a defined floating-point standard. |
| Rule | Description | |
|---|---|---|
| Rule 2.1 | (required) | Assembly language shall be encapsulated and isolated. |
| Rule 2.2 | (required) | Source code shall only use /* ... */ style comments. |
| Rule 2.3 | (required) | The character sequence /* shall not be used within a comment. |
| Rule 2.4 | (advisory) | Section of code should not be "commented out". |
| Rule | Description | |
|---|---|---|
| Rule 3.1 | (required) | All usage of implementation-defined behaviour shall be documented. |
| Rule 3.2 | (required) | The character set and the corresponding encoding shall be documented. |
| Rule 3.3 | (advisory) | The implementation of integer division in the chosen compiler should be determined, documented and taken into account. |
| Rule 3.4 | (required) | All uses of the #pragma directive shall be documented and explained. |
| Rule 3.5 | (required) | If it is being relied upon, the implementation-defined behaviour and packing of bitfields shall be documented. |
| Rule 3.6 | (required) | All libraries used in production code shall be written to comply with the provisions of this document, and shall have been subject to appropriate validation. |
| Rule | Description | |
|---|---|---|
| Rule 4.1 | (required) | Only those escape sequences that are defined in the ISO C standard shall be used. |
| Rule 4.2 | (required) | Trigraphs shall not be used. |
| Rule | Description | |
|---|---|---|
| Rule 5.1 | (required) | Identifiers (internal and external) shall not rely on the significance of more than 31 characters. |
| Rule 5.2 | (required) | Identifiers in an inner scope shall not use the same name as an identifier in an outer scope, and therefore hide that identifier. |
| Rule 5.3 | (required) | A typedef name shall be a unique identifier. |
| Rule 5.4 | (required) | A tag name shall be a unique identifier. |
| Rule 5.5 | (advisory) | No object or function identifier with static storage duration should be reused. |
| Rule 5.6 | (advisory) | No identifier in one namespace should have the same spelling as an identifier in another namespace, with the exception of structure and union member names. |
| Rule 5.7 | (advisory) | No identifier name should be reused. |
| Rule | Description | |
|---|---|---|
| Rule 6.1 | (required) | The plain 'char' type shall be used only for the storage and use of character values. |
| Rule 6.2 | (required) | 'signed' and 'unsigned char' type shall be used only for the storage and use of numeric values. |
| Rule 6.3 | (advisory) | typedefs that indicate size and signedness should be used in place of the basic types. |
| Rule 6.4 | (required) | Bit fields shall only be defined to be of type 'unsigned int' or 'signed int'. |
| Rule 6.5 | (required) | Bit fields of type signed int shall be at least 2 bits long. |
| Rule | Description | |
|---|---|---|
| Rule 7.1 | (required) | Octal constants (other than zero) and octal escape sequences shall not be used. |
| Rule | Description | |
|---|---|---|
| Rule 8.1 | (required): | Functions shall have prototype declarations and the prototype shall be visible at both the function definition and call. |
| Rule 8.2 | (required): | Whenever an object or function is declared or defined, its type shall be explicitly stated. |
| Rule 8.3 | (required): | For each function parameter the type given in the declaration and definition shall be identical, and the return type shall also be identical. |
| Rule 8.4 | (required): | If objects or functions are declared more than once their type shall be compatible. |
| Rule 8.5 | (required): | There shall be no definitions of objects or functions in a header file. |
| Rule 8.6 | (required): | Functions shall be declared at file scope. |
| Rule 8.7 | (required): | Objects shall be defined at block scope if they are only accessed from within a single function. |
| Rule 8.8 | (required): | An external object or function shall be declared in one and only one file. |
| Rule 8.9 | (required): | An identifier with external linkage shall have exactly one external definition. |
| Rule 8.10 | (required): | All declarations and definitions of objects or functions at file scope shall have internal linkage unless external linkage is required. |
| Rule 8.11 | (required): | The 'static' storage class specifier shall be used in definitions and declarations of objects and functions that have internal linkage. |
| Rule 8.12 | (required): | When an array is declared with external linkage, its size shall be stated explicitly or defined implicitly by initialisation. |
| Rule | Description | |
|---|---|---|
| Rule 9.1 | (required) | All automatic variables shall have been assigned a value before being used. |
| Rule 9.2 | (required) | Braces shall be used to indicate and match the structure in the non-zero initialisation of arrays and structures. |
| Rule 9.3 | (required) | In an enumerator list, the "=" construct shall not be used to explicitly initialise members others than the first, unless all items are explicitly nitialised. |
| Rule | Description | |
|---|---|---|
| Rule 10.1 | (required) | The value of an expression of integer type shall not be implicitly converted to a different underlying type if: ... |
| Rule 10.2 | (required) | The value of an expression of floating type shall not be implicitly converted to a different type if: ... |
| Rule 10.6 | (required) | A "U" suffix shall be applied to all constants of unsigned type. |
| Rule | Description | |
|---|---|---|
| Rule 11.1 | (required) | Conversions shall not be performed between a pointer to a function and any type other than an integral type. |
| Rule 11.2 | (required) | Conversions shall not be performed between a pointer to object and any type other than an integral type, another pointer to object type or a pointer to void. |
The Curiously Recurring Template Pattern (CRTP) is a C++ idiom.
Mixin Inheritance: In C++, a class can be defined to inherit from its own template argument
template <typename T>
class Mixin : T
{
}an architecture that leads you to having to do lots of tiny changes in lot of classes, whether related (as in a hierarchy) or not, is typically a code smell
'Single Responsibility': each class has only one responsibility, and therefore has only one reason to change.
'Open-Closed' Principle states that a type is open for extension but closed for modification.
"principle of least surpise"
Polymorphism means the ability to assume several forms.
- Single Responsibility Principle (SRP)
- Open-Close Principle (OCP): A a type is open for extension but closed for modifications.
- Liskov Substitution Principle (LSP): If an interface takes an object of type Parent, it should equally take an object of type Child without anything breaking.
- Interface Segregation Principle (ISP): segregate parts of a complicated interface into separate interfaces so as to avoid forcing implementors to implement functionality that they do not really need.
- Dependency Inversion Principle (DIP):
The Guideline Support Library (GSL) (https://github.com/Microsoft/GSL) is a set of functions and types that are suggested by the C++ Core Guidelines. This library includes many types, among them the owner type used to indicate ownership of a pointer.
Common approaches related to the creation of objects.
Return Value Optimization (RVO) is a compiler feature that specifically prevents those extra copies being made (since they don’t really affect how the code behaves).
Prototype Pattern: a model object that we can make copies of, customize those copies, and then use them.
In other programming languages, compiled binaries include not just executable code but plenty of metadata, and serialization is possible through a feature called reflection—so far unavailable in C++.
The trouble with global static objects is that their initialization order in different compilation units is undefined. This can lead to nasty effects, like one global object referring to another when the latter hasn’t yet been initialized.