问题
Our company are now ISO-13485 (Medical devices) and wants to use MISRAC2012. I read the standard, but I cannot figure out whether or not I am allowed to disable some rules if I think it could improve both stability and readability.
Two examples:
MISRA only allows 1 return statement per function. This often lead to nested conditional structures that look like Christmas tree. I really don't think this rule increase safeness because it makes the code less readable and more error prone.
MISRA only accept functions that have a prototype, even for static ones. This allows the programmer to place his functions anywhere in the file without respect of the calling order. Without prototype the main function has to be the latest function in the file and multi-function recursion is not possible because a function can only call the one declared above itself.
If I want to disable these two rules, can I do it? Would any customer blame me for this?
回答1:
MISRA-C:2012 has 3 categories that all directives and rules sort under:
- Mandatory. You must follow these and you are not allowed to make deviations.
- Required. You must follow these, but you are allowed to break them if you raise a formal deviation from the rule. You need a good reason why.
- Advisory. It is recommended to follow these, but you can break them without raising a formal deviation (although raising a deviation is recommended practice).
The idea behind deviations is that your company should have a routine to deal with them, such as an internal quality errand or something to bring up during code review meetings etc. The idea is that someone else except yourself must be involved in the process of creating a deviation, preferably someone with extensive C knowledge. This is described in MISRA-C 5.4 and there's also an additional guidance document called MISRA Compliance:2016 that might be helpful.
My personal advise for how to implement deviations, is to not allow them at all on case-by-case basis. Instead, a separate coding standard document for the company should be established - you need some manner of document to claim MISRA compliance anyway. This document should contain a list of all company-wide deviations. If there is a need to deviate, the company-wide document must be updated. This actually saves you from implementing a lot of bureaucracy routines and it saves you from various less experienced programmers coming up with weird ideas, just because they don't understand the MISRA-C rationale for the rule.
As for the one return statement per function, it is in my opinion a known defect in MISRA-C inherited from IEC 61508 (I think I'm the only one who actually bothered researching where the requirement comes from). You should raise a permanent deviation against the rule, since it is nonsense. Personally I rephrased the requirement as "functions should not have more than one return statement, unless several return statements leads to more readable code". This covers what was hopefully the true intention of the rule, namely to avoid spaghetti programming.
MISRA only accept functions that have a prototype, even for static ones. This allows the programmer to place his functions anywhere in the file without respect of the calling order. Without prototype the main function has to be the latest function in the file and multi-function recursion is not possible because a function can only call the one declared above itself.
I don't believe this makes any sense, seems like you are trying to solve a problem which doesn't exist. You should avoid accidental recursion by 1) actually knowing what you are doing and 2) use static analysis tools, as required by MISRA.
If you want the call stack to be func1() -> func2() -> func3() and block func2() or func3() from calling func1(), that is best solved with proper program design. Giving the functions intuitive names and using common sense will get you very far.
If that's not enough, then you can split your translation unit in two and create a separate h/c file pair for the internals. The risk you describe is mostly a problem if you have very long source files with a lot of functions in them, to the point where the programmer is losing track of them. That too is a good indication that the file (and/or the functions) should be split in several.
As for the rationale behind this MISRA rule, it is a very sound one, namely to block old C90 crap from "inventing" a calling convention (implicit int return type, making up parameters etc), just because the compiler can't find a function prototype. You definitely should not deviate from this rule.
回答2:
Rule 15.5 (A function should have a single point of exit at the end) is a Advisory rule. So, should your in-house processes so document, you can disapply this Rule.
Rule 8.2 (Functions shall be in prototype form) is a Required Rule, for (IMHO) sound reason - in that it ensures that you explicitly define the function return type and number and types of all parameters, thus avoiding undefined behaviour.
Should you so desire, you can Deviate the Guideline, but this requires you to justify that decision!
回答3:
You can follow the deviation process, and part of that process is the deviations are reviewed by qualified technical personnel. Deviations can cover individual instances of non-compliancy and can also be project-wide.
So how would you justify the project-wide deviations that you are asking for?
I would argue at best, each individual violation should be reviewed. In some cases your reasoning, for example, deep nesting can be unreadable/unmaintainable, must be weighed by the question why are they so deep in the first place? In other words, maybe the function is doing too much and needs to be broken into smaller modules.
I'm assuming you're using a static analysis tool that's smart enough to provide a means to not keep reporting a violation once the deviation has been approved.
来源：https://stackoverflow.com/questions/46551609/am-i-allowed-to-choose-to-disable-these-two-misra-rules-one-statement-per-funct