Misra-C Programming specification as an industrial standard

From: http://blog.csdn.net/myan/article/details/1919

Misra-C Programming specification as an industrial standard

Misra (the motor industry software reliability Association Automotive Industry software reliability Association) is a UK-based multinational Automotive Industry Association, which includes most European and American automakers. Its core mission is to provide services and assistance to the automotive industry and help the factory develop secure and highly reliable embedded software. The Organization's most famous achievement is the so-called Misra C coding standard, which includes 127 C language encoding standards and is generally considered to be fully compliant with these standards, your C code is readable, reliable, portable, and easy to maintain. Recently, many embedded developers use Misra
C to measure their encoding style, such as the famous uC/OS-II is proud to claim that 99% of their compliance with the Misra standard. The "Embedded Development Magazine" is also devoted to everyone's learning. Code standards are usually a company's customized "soil policy". Some people have made standards and are still widely recognized. This has aroused my strong interest. It is a pity that this standard text requires a lot of money to buy, and the price is very expensive in just dozens of pages. Misra has published some documents on the Internet, including the Clarification report on Misra C coding standard. You can roughly guess what the Misra standard is. I have carefully read these documents and read other introductory documents to get a general idea of the main content of the Misra standard. These terms are indeed extraordinary, and play a good guiding role in the Code Quality Management of C/C ++ language engineering projects. For most software development enterprises, you can create your own specifications by making appropriate modifications on the basis of Misra. Of course, there are also some too strict things, which requires flexible handling by various development departments. In my personal experience, although coding standards are simple, they must be fully implemented without compromise. The development department must be highly organized and disciplined, and have a good code review mechanism. Therefore, strict compliance with coding standards is a proof of the strength of a Development Department.

It is impossible to list all the rules here (in fact, I did not see one of them in the official text). I will only list some interesting terms, so that you can understand the style of Misra. For more information, visit www.misra.org. uk.

Rule 1. strictly follows the ANSI c89 standard and does not allow any extensions.

Rule 3. If you want to embed the assembly language, you must wrap all the Assembly statements in the C function. In addition, these functions only have Assembly statements, and there are no general C statements.

Rule 7. Do not use the ternary operator (? :)

Rule 10. Do not leave the commented-out waste code.

Rule 11. All identifiers cannot exceed 31 characters.

Rule 12. The variable names in different namespace cannot be the same.
For example:
Typedef struct mystruct {...} mystruct; (Violation)

Struct person {
Char * Name;
...
};

Char name [32]; (Violation)

Rule 13. do not use char, Int, float, double, long, and other basic types. You should use your own defined types to display the type size, such as char8, uchar8, int16, int32, float32, long64, ulong64.

Rule 14. Char type is not allowed. It must be declared as unsigned char or signed Char.

Rule 18. All numeric constants should be suffixed to indicate the type, such as 51l, 42u, 34.12f, etc.

Rule 19. Disable the octal number. (Because constants such as 086u are easy to misunderstand ).

Rule 21. do not define an object with the same name as an identifier in the external scope to avoid overwriting the identifier in the external scope.

Rule 23. Objects with file Scopes should be named static as much as possible.

Rule 24. In the same compilation unit, the same identifier should not be recognized by colleagues as internal links or external links.

Here I will give a brief description:

We usually name some variables in the header file as "external links", such:
Extern uint32 g_count; // It is also called a variable Declaration (corresponding to the variable definition, without allocating actual space)

This is good for the. c file that "uses" this variable, because g_count always maintains the nature of external links. However, for the. c file defining g_count (actually allocating space), if the header file contains the preceding header file, there is a conflict between the internal link and the external link in this compilation unit. The solution is to define the g_count file and try not to include the header file named g_count. I personally feel that this is not always done, especially when dealing with legacy code.

Rule 25. identifiers with external links should be declared only once.

Rule 27. external objects cannot be named in multiple files.

Rule 28. forbidden to use the register keyword.

Rule 29. The initial value must be assigned before the Automatic Object (stack object) is used.

Rule 33. the right expression of the operator & | must not have side-effects ).
That is, expressions like if (x = 20 & + y = 19) are forbidden.

Rule 35. No value assignment operation is allowed in the expression that returns a Boolean value.
That is to say, we commonly use if (! (FP = fopen ("fname", "R") {/* Error */}
Forbidden.

Rule 37. do not apply a bit to the number of signed characters. For example, 1 <4 will be disabled and 1ul must be written <4;

Rule 39. do not apply the unary "-" operator to a signed expression.

Rule 40. do not apply the sizeof operator to expressions with side effects.

Rule 42. Except for loop control statements, comma expressions are not allowed.

Rule 44. Explicit transformation of redundancy is prohibited. For example, double Pi = (double) 3.1416f;

Rule 45. prohibit forced transformation from any type to pointer, and prohibit forced transformation from pointer to any type.
Example: void * P = (void *) 0xffff8888ul;

Rule 49. Check whether the test value is zero.

Rule 50. Do not explicitly judge the equality and inequality of floating point numbers.

Rule 52. Do not leave the code "never used.

Rule 53. All non-empty statements must have side effects.

Rule 55. labels are not allowed except for switch statements ).

Rule 56. Do not use Goto.

Rule 57. Do not use continue.

Rule 58. Break is not allowed except for the switch statement.

Rule 59. If, else if, else, while, do... while, for statement blocks must be included in.

Rule 60. Any if... else if statement must end with an else. For example:
If (ANS = 'y '){
...
}
Else if (ANS = 'n '){
...
}
Else if (ANS = 'C '){
...
}
Else {
;
}

Rule 67. The value of the cyclic counter cannot be modified in the circular body.

Rule 70. prohibit any direct and indirect recursive function calls.

Rule 82. Each function can have only one launch point.

Rule 86. If a function may return an error message, it must be tested after being called.

Rule 92. Shouldn't be used # UNDEF

Rule 95. Do not pass macros as parameters to macro functions.

Rule 98. In a macro definition, the # Or # symbol can only appear once.

Rule 101. The pointer operation is not allowed (Instead, the array subscript operation is performed ).

Rule 102. Forbid pointers exceeding two levels.

Rule 104. Do not use a very large pointer to a function.

Rule 106. Do not pass the stack object address to the object in the external scope.

**************************************** ****************************
The following rules are applicable to real-time embedded systems and may not be applicable to other types of development, such:

Rule 118. Do not use dynamic heap allocation (that is, do not use malloc, calloc, or realloc ).

Rule 119. Disable errno.

Rule 120. Disable offsetof.

Rule 121. Disable <locale. h>

Rule 122. Disable setjmp and longjmp.

Rule 123. Disable <signal. h>

Rule 124. Disable <stdio. h> (printf and scanf are unavailable !)

Rule 125. Prohibit the use of atoi, atof, atol. (I am in favor of this. We recommend using functions such as strtol and strtodd)

Rule 126. Abort, exit, and getenv are prohibited.

Rule 127. Disable <time. h>