问题描述
我们的公司现在是ISO-13485(医疗设备)，并且希望使用MISRAC2012.我阅读了该标准，但是如果我认为它可以提高稳定性和可读性，则无法确定是否可以禁用某些规则.
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.
两个示例:
MISRA每个函数仅允许1个返回语句.这通常会导致嵌套的条件结构看起来像圣诞树.我真的不认为这条规则会增加安全性，因为它会使代码的可读性降低并且更容易出错.
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仅接受具有原型的功能，即使是静态功能也是如此.这允许程序员在不考虑调用顺序的情况下将其函数放置在文件中的任何位置.没有原型，主要功能必须是文件中的最新功能，并且多功能递归是不可能的，因为一个功能只能调用自身之上声明的功能.
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?
推荐答案
MISRA-C:2012具有3个类别，所有指令和规则都归类于以下类别:
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).
偏差背后的想法是，您的公司应该有常规的应对措施，例如内部质量差事或在代码审查会议期间提出的东西等.想法是，除您本人外，其他人也必须参与其中.产生偏差的过程，最好是具有丰富C知识的人.这在MISRA-C 5.4中进行了描述，并且还有一个名为 MISRA合规性:2016 可能会有所帮助.
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.
我对如何实施偏差的个人建议是，完全不允许因个案而异.相反，应该为公司建立单独的编码标准文档-无论如何，您都需要某种文档来声明MISRA的合规性.该文档应包含所有整个公司范围内的偏差的列表.如果需要偏离，则必须更新公司范围的文档.实际上，这使您不必执行许多官僚主义例程，并且使您脱离了各种经验不足的程序员，这些程序员提出了奇怪的想法，只是因为他们不了解MISRA-C对该规则的依据.
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.
对于每个函数一个返回语句，我认为这是 MISRA-C中的已知缺陷，继承自IEC 61508 (我认为我是唯一真正研究需求的来源的人).您应该对规则提出永久性的偏离，因为这是无稽之谈.我个人将要求改为:函数不应具有多个return语句，除非多个return语句导致可读性更高的代码".这涵盖了该规则的真正意图，即避免意大利面条编程.
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.
我认为这没有任何意义，似乎您正在尝试解决一个不存在的问题.您应该避免意外递归，方法是:1)实际知道自己在做什么，以及2)按照MISRA的要求使用静态分析工具.
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.
如果您希望调用堆栈为func1()-> func2()-> func3()并阻止func2()或func3()调用func1()，则最好通过适当的程序设计来解决.为函数提供直观的名称并使用常识将使您受益匪浅.
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.
如果这还不够，那么您可以将翻译单元一分为二，并为内部创建单独的h/c文件对.如果您的源文件很长且其中包含许多功能，那么描述的风险通常是个问题，以至于程序员会失去对它们的了解.这也很好地表明了文件(和/或功能)应该分成几部分.
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.
关于此MISRA规则背后的原理，这是一个非常合理的方法，即阻止旧的C90废话发明"调用约定(隐式int返回类型，构成参数等)，只是因为编译器可以找不到函数原型.您绝对不应偏离此规则.
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.
这篇关于我是否可以选择禁用这两个MISRA规则:每个函数一个语句和强制函数原型?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！