MISRA - as a C-programming specification for industrial standards
MISRA (The Motor Industry Software Reliability Association Automotive Industrial Software Reliability League) is a multinational automotive industry association in the UK, and its members include most European manufacturers. Its core mission is to provide services and assistance for the automotive industry to help the factory develop secure, highly reliable embedded software. The most famous result of this organization is the so-called Msra C Coding Standard. This standard includes 127 C language coding standards, which usually believe that if you can completely follow these standards, your C code is easy to read, reliable, and portable. And easy to maintain. Recently, many embedded developers are measuring their own coding style with Msra C, such as the famous UC / OS-II, which is proud to claim 99% to comply with MISRA standards. "Embedded Development Magazine" also specially filed a call to everyone. The code specification is usually a company's own custom "earth policy", actually has a standard, and it has also been widely recognized, which can't help but attract my interested interest. Unfortunately, this standard text needs to spend money to buy, and short tens of pages, the price is very expensive. MISRA published some documents online, where the Clarification report on Misra C Coding Standard, from the middle you can roughly guess what is the MISRA standard itself. I read these documents carefully and won the main content of the MISRA standard by reading other introductory documents. These provisions have there have been people, and the code quality management of the C / C language project can play a good guidance effect. For most software development companies, they can form their own on the basis of MISRA. specification. Of course, there are some more harsh things that require flexibility in various development departments. I personally experience, although the coding specification is very simple, but it is fully implemented, unclusions, requires the development department to have high organizational and discipline, and have a good code review mechanism. Therefore, if the coding specification can be strictly complied with, it is a certificate of development department.
It is impossible to list all rules one by one (in fact text I have not seen it), only some interesting terms are listed, let everyone have the opportunity to understand Misra style. Specific content, interested friends can go to www.misra.org.uk to understand.
Rule 1. Strictly follow the ANSI C89 standard and do not allow any expansion.
Rule 3. If you want to embed assembly language, you must pack all assembled statements in the C function, and there are only compilation statements in these functions, there is no conventional C statement. Rule 7. Do not use the three-yuan operator (?:)
Rule 10. Do not reside the annotated waste code.
Rule 11. All identifiers do not exceed 31 characters.
Rule 12. Variables in different spaces must not be the same. For example: typedef struct mystruct {...} mystruct; (illegal)
Struct Person {char * name; ...};
Char Name [32]; (illegal)
Rule 13. Do not use basic types of CHAR, INT, FLOAT, DOUBLE, LONG, should display the size of the type, such as Char8, Uchar8, INT16, INT32, FLOAT32, long64, ulong64, etc.
Rule 14. Do not use type char, must be displayed as unsigned char or signed char.
Rule 18. All digital constants should add a suitable suffix representation, such as 51L, 42U, 34.12F, and the like. Rule 19. It is forbidden to use an octal number. (Because the constant of 086u is easy to cause misconceptions).
Rule 21. Do not define objects with an identifier in an external scope to avoid obscuring an identifier in an external scope.
Rule 23. A object with a file scope is called Static as much as possible.
Rule 24. In the same compilation unit, the same identifier should not have a colleague with an internal link and an external link.
Here I will make a little description: We usually be called "external link" in the header file, such as: extern uint32 g_count; // As a variable variable declaration (corresponding to variable definition, do not assign actual space)
This is very good for "use" this variable. This is very good because g_count always maintains the external link nature. However, for the .c file of the G_Count (actual allocation space), if the above-described header file is included, the conflict between internal links and external links occurs in this compilation unit. The solution is that the file defines the G_Count to do not include the header files who have a name g_count. Personally, this is not done at all times, especially when dealing with legacy code.
Rule 25. Identifiers with external link properties should only declare once.
Rule 27. External objects must not be called in multiple files.
Rule 28. It is forbidden to use the Register keyword.
Rule 29. Automatic object (stack object) must be assigned before use.
Rule 33. The right side of the operator && and || must not have side effects (Side-Effect). That is, the expression of IF (x == 20 && Y == 19) is disabled.
Rule 35. You must not assign an assignment in an expression that returns a Boolean value. That is, we often use IF (! (Fp = fopen ("fname", "r"))) {/ * error * /} is disabled.
Rule 37. No bitction is applied to the symbol number, such as 1 << 4 will be disabled, must be written 1 ul << 4;
Rule 39. No one yuan "-" operator is applied to a symbolic expression.
Rule 40. The SIZEOF operator cannot be applied to an expression of side effects.
Rule 42. In addition to loop control statements, a comma expression is not allowed.
Rule 44. Disables redundant explicit transformation. For example: double pi = (double) 3.1416F;
Rule 45. It is forbidden from arbitrary types to the pointer to disable from the pointer to any type of forced transformation. For example: void * p = (void *) 0xffff8888ul;
Rule 49. Displays whether the test value is zero.
Rule 50. Do not explicitly determine the phase of floating point numbers and inequality.
Rule 52. Do not legacy "never use" code.
Rule 53. All non-empty statements must have side effects.
Rule 55. In addition to the Switch statement, you must not use the label.
Rule 56. Do not use GOTO.
Rule 57. Do not use Continue.
Rule 58. In addition to the Switch statement, you must not use BREAK.
Rule 59. IF, Else If, else, while, do..while, for strategy must be enclosed in {}.
Rule 60. Any if..else if statement, you must have a final ELSE. For example: if (ANS == 'Y') {...} else if (ANS == 'n') {...} else f (ANS == 'c') {...} else {; Rule 67. The value of the loop counter must not be modified within the cycle.
Rule 70. No direct and indirect recursive function calls.
Rule 82. Each function can only have a launch point.
Rule 86. If a function may return an error message, you must test after calling.
Rule 92. Should not use #undef
Rule 95. Do not pass macros as a parameter to macro function
Rule 98. In a macro definition, # or ## symbol can only appear once.
Rule 101. It is forbidden to operate (in the case of an array subscript).
Rule 102. It is forbidden to more than two stages.
Rule 104. It is forbidden to use a very amount of pointer to function.
Rule 106. Do not pass the address of the stack object to the object of the external scope.
*********************************************************** *****************************************************************
Rule 118. It is forbidden to use dynamic reactor allocation (not Malloc, Calloc, and Realloc).
Rule 119. It is forbidden to use Errno.
Rule 120. It is forbidden to use OFFSetof.
Rule 121. Prohibition of
Rule 122. It is forbidden to use SetJMP, Longjmp.
Rule 123. Prohibited use
Rule 124. Prohibited use
Rule 125. It is forbidden to use ATOI, ATOF, ATOL. (I am very agreeable, it is recommended to use STRTOL, STRTOD and other functions)
Rule 126. It is forbidden to use Abort, EXIT, GETENV.
Rule 127. Prohibited
