我可以选择禁用这两个MISRA规则：每个函数一个语句和强制函数原型吗？
我们公司现在是ISO-13485（医疗设备），并希望使用MISRAC2012。 我阅读了标准，但如果我认为可以提高稳定性和可读性，我无法弄清楚是否可以禁用某些规则。
两个例子：
MISRA每个函数只允许1个return语句。 这通常会导致嵌套的条件结构看起来像圣诞树。 我真的不认为这条规则会增加安全性，因为它会降低代码的可读性并且更容易出错。
MISRA只接受具有原型的function，即使是静态function。 这允许程序员将其function放在文件中的任何位置而不考虑调用顺序。 没有原型，main函数必须是文件中的最新函数，并且多函数递归是不可能的，因为函数只能调用上面声明的函数。
如果我想禁用这两个规则，我可以这样做吗？ 有客户会因此而责备我吗？
MISRA-C：2012有3个类别，所有指令和规则排序如下：
- 强制性。 你必须遵循这些，不允许你做出偏差。
- 需要。 你必须遵循这些，但如果你提出正式的规则偏差，你可以打破它们。 你需要一个很好的理由。
- 咨询。 建议遵循这些，但你可以打破它们而不会产生正式偏差（尽管建议偏差是建议的做法）。
偏差背后的想法是你的公司应该有一个例程来处理它们，例如内部质量差事或在代码审查会议期间提出的事情等。这个想法是除了你自己以外的其他人必须参与创建过程偏差，最好是具有广泛C知识的人。 这在MISRA-C 5.4中有描述，还有一个名为MISRA Compliance：2016的附加指导文件可能会有所帮助。
我个人对如何实施偏差的建议是根据具体情况不允许这些偏差。 相反，应该建立一个单独的公司编码标准文件 – 无论如何，您需要某种方式的文件来声明MISRA合规性。 本文档应包含所有公司范围偏差的列表。 如果需要偏离，则必须更新公司范围的文档。 这实际上可以帮助您避免实施大量的官僚程序，并且可以让您从各种经验不足的程序员那里获得奇怪的想法，只因为他们不理解MISRA-C规则的基本原理。
至于每个函数的一个返回语句，在我看来，MISRA-C中的一个已知缺陷inheritance自IEC 61508 （我认为我是唯一一个真正困扰研究需求来源的人）。 你应该对规则提出永久性的偏差，因为这是无稽之谈。 我个人将这个要求改为“函数不应该有多个return语句，除非几个return语句导致代码更易读”。 这涵盖了规则的真正意图，即避免意大利面条编程。
MISRA只接受具有原型的function，即使是静态function。 这允许程序员将其function放在文件中的任何位置而不考虑调用顺序。 没有原型，main函数必须是文件中的最新函数，并且多函数递归是不可能的，因为函数只能调用上面声明的函数。
我不相信这有任何意义，似乎你正试图解决一个不存在的问题。 你应该避免意外的递归1）实际知道你在做什么，2）使用静态分析工具，按照MISRA的要求。
如果你想调用堆栈为func1（） – > func2（） – > func3（）并且调用func1（）来阻止func2（）或func3（），那么最好通过适当的程序设计来解决。 赋予function直观的名称和使用常识将使您走得更远。
如果这还不够，那么您可以将翻译单元拆分为两个，并为内部创建单独的h / c文件对。 如果您有很长的源文件，其中包含很多函数，那么您描述的风险主要是一个问题，直到程序员正在失去对它们的追踪。 这也是一个很好的迹象，表明文件（和/或函数）应该分成几个。
至于这个MISRA规则背后的基本原理，它是一个非常合理的，即阻止旧的C90垃圾“发明”一个调用约定（隐式int返回类型，组成参数等），只是因为编译器找不到function原型。 你绝对不应该偏离这个规则。
规则15.5（ 一个函数最后应该有一个退出点 ）是一个咨询规则。 因此，如果您的内部流程如此记录，您可能会对此规则不满意 。
规则8.2（ 函数应为原型forms ）是（IMHO）声音原因的必需规则 – 因为它确保您明确定义函数返回类型以及所有参数的数量和类型，从而避免未定义的行为。
如果你愿意，你可以偏离指南，但这需要你certificate这个决定是正确的！
您可以遵循偏差过程，并且该过程的一部分是由合格的技术人员审查偏差。 偏差可以涵盖不合规的个别情况，也可以在整个项目范围内。
那么您如何certificate您要求的项目范围内的偏差？
我会充其量争辩，应该审查每个违规行为。 在某些情况下，你的推理，例如，深度嵌套可能是不可读/不可维护的，必须先考虑为什么它们首先如此深入？ 换句话说，function可能做得太多，需要分解成更小的模块。
我假设您正在使用静态分析工具，该工具足够聪明，可以提供一种方法，一旦偏差得到批准，就不会继续报告违规行为。