From: Development and validation of a safe communication protocol compliant to railway standards
Directive | Class | Description | Comment |
---|---|---|---|
1.1 | Mandatory | Any implementation-defined behavior on which the output of the program depends shall be documented and understood | The description of the implementations Followed a pattern that made it easier to understand its content and goals |
2.1 | Mandatory | All source files shall compile without any compilation errors | No errors or warnings during compilation. |
3.1 | Mandatory | All code shall be traceable to documented requirements | Most of the requirements names are reused in the code; it is easy to trace everything to its original requirements. |
4.4 | Advisory | Sections of code should not be “commented out” | No commented code found. |
4.5 | Advisory | Identifiers in the same name space with overlapping visibility should be typographically unambiguous | Identifiers are self-explanatories, no ambiguity found. |
4.6 | Advisory | Typedefs that indicate size and signedness should be used in place of the basic numerical types | Functions use raw integers to indicate a state/type. |
4.7 | Mandatory | If a function returns error information, then that error information shall be tested | There is error handling in all the functions related to the protocol, haven’t seen any tests to prove their efficiency. |
4.8 | Advisory | If a pointer to a structure or union is never dereferenced within a translation unit, then the implementation of the object should be hidden | Pointers have their object implementation hidden. |
4.9 | Advisory | A function should be used in preference to a function-like macro where they are interchangeable | Function-like macros are rare in the code |
4.12 | Mandatory | Dynamic memory allocation shall not be used | Not found. |