Reglas Misra

MISRA C Rules
The following is a summary of the MISRA C rules. This document is not a definitive list these rules, which are only and completely defined in "MISRA Guidelines for the use of the C language in vehicle based software".

Environment
1 (req): 2 (adv): 3 (adv): All code shall conform to ISO 9899 standard, with no extensions permitted. Code written in languages other than C should onlybe used if there is a defined interface standard for object code to which the compiler/assembler for both languages conform Assembler language functions that are called from C should be written as C functions containing only in-line assembly language, and in-line assembly language should not be embedded in normal C code Provision should be made for appropriate run-time checking

4 (adv):

CharacterSets
5 (req): 6 (req): 7 (req): 8 (req): Only those characters and escape sequences that are defined in the IOS C standard shall be used Values of character types shall be restricted to a defined and documented subset of ISO 10646-1 Tri-graphs shall not be used Multibyte characters and wide string literals shall not be used

Comments
9 (req): 10 (adv): Comments shall not be nested Sections ofcode should not be commented out

Identifiers
11 (req): Identifiers shall not rely on the significance of more than 31 characters. Compiler/linker shall check to ensure that 31 char significance and case sensitivity are supported for external identifiers Identifiers in different namespace shall not have the same spelling. Structure members are an exception

12 (adv):

Types
13 (adv): 14 (req): 15(adv): 16 (req): 17 (req): The basic types char, int, short, long, double and float should not be used. Specific-length equivalents should be typedef’d for the specific compiler, and these names used in the code The type char shall always be declared as unsigned char or signed char. See rule 13 Floating point implementations should comply with a defined floating point standard The underlying bitrepresentation of floating point numbers shall not be used in any way by the programmer typedef names shall not be reused

Constants
18 (adv): 19 (req): Numeric constants should be suffixed to indicate type if possible Octal constants shall not be used Zero is okay

Declarations and Definitions
20 (req): 21 (req): 22 (adv): 23 (adv): 24 (req): 25 (req): 26 (req): 27 (adv): 28 (adv): 29 (req): Allobject and function identifiers shall be declared before use Identifiers in an inner scope shall not use the same name as an identifier in an outer scope, and therefore hide that identifier Declaration of object should be at function scope unless a wider scope is necessary All declarations at file scope should be static if possible Identifiers shall not simultaneously have both internal and externallinkage in the same translation unit An identifier with an external linkage shall have exactly one external definition If objects are declared more than once they shall have compatible declarations External objects should not be declared in more than one file The register storage class specifier should not be used The use of a tag shall agree with its declaration

Initialisation
30 (req): 31(req): 32 (req): All automatic variables shall have a value assigned to them before use Braces shall be used to indicate and match the structure in the non-zero initialisation of arrays and structures In an enumerator list the = construct shall not be used to explicitly initialise members other than the fist unless it is used to initialise all items

Operators
33 (req): 34 (req): 35 (req): 36 (adv): 37(req): 38 (req): 39 (req): 40 (adv): 41 (adv): 42 (req): The right hand operand of a && or || shall not contain side effects The operands of a logical && or || shall be primary expressions A single identifier, constant or parenthesised expression Assignment operators shall not be used in expressions that return Boolean values Logical operators shall not be confused with bitwise operators...