选择指南: MISRA 1998、MISRA 2004或MISRA 2012？

Question

我一直在想，一个项目/团队/公司如何选择或有资格选择要遵循的特定指南，如MISRA 1998/2004/2012？人们应该如何知道和决定哪条准则对于项目的合格来说是足够的(成本、时间和质量)？

(我知道他的问题有点直截了当，但任何答案都将不胜感激)

Answer 1

这通常是应用程序领域的一个要求。您将拥有安全标准，规定使用编程语言的安全子集。这一要求可以来自"SIL“标准，如工业IEC 61508、汽车IEC 26262、航空航天DO-178等。在这样的关键任务系统中，除了使用MISRA-C之外，您可能没有其他选择。

但MISRA-C也正在成为所有嵌入式系统的行业标准，无论其性质如何。原因是显而易见的:没有人，无论应用程序的领域，喜欢坏的，低质量的充满错误的软件。

介绍MISRA-C，以及公司的编码指南、样式规则、静态分析、版本控制...所有这些都将显著提高最终产品的质量。这将迫使程序员在整体上变得更加专业的同时，学习C语言。

也就是说，MISRA-C不一定是最适合每家公司的规则集。它主要适用于嵌入式系统。对于其他类型的应用程序，像CERT-C这样的东西可能更相关。使用这些众所周知的标准之一是很方便的，因为这样您就可以使用静态分析器自动执行测试。

这里的关键是，每个生产软件的半专业公司都需要某种专注于禁止不良实践的编码规则。一些公司倾向于过于关注不重要的风格细节，比如在哪里放置{，而他们应该专注于真正提高软件质量的事情，比如“我们应该避免编写像函数一样的宏”。

编码规则应与开发例程集成。为一个单独的项目实现MISRA-C没有多大意义。有相当多的工作涉及到它的启动和运行。

非常重要的是，您至少要有一个，最好是几个具有多年经验的C语言老手，让他们负责编码规则。他们需要阅读MISRA文档的每一个肮脏细节，并决定哪些规则对公司有意义。其中一些规则很难理解。并不是所有的方法在每种情况下都有意义。如果您的开发团队只由初学者或中等经验的程序员组成，而您决定严格遵循MISRA，那么这将是一个糟糕的结局。你需要至少一个有足够知识的资深程序员来决定应该遵循哪些规则，哪些规则应该背离。

至于选择哪个版本的MISRA-C，请始终使用最新版本: 2012。它已经被清理了很多，一些奇怪的规则也被删除了。它还支持C99，这与旧版本不同。

Answer 2

代码应编写为具有某些所需的属性(质量标准)。一些质量标准实际上总是需要的，比如正确性、可读性、可维护性(即使在这里也有例外，例如，如果你为混淆的c竞赛或暗箱操作的c竞赛编写代码)。其他质量标准仅与某些项目或组织相关，例如可移植到16位计算机。

良好的编码规则通常支持一个或多个质量标准。然而，它可能会与其他人发生冲突。存在大量已建立的编码规则，它们支持通常所需的质量标准，但对其他标准没有显著的负面影响。其中许多已经在很久以前就被识别出来了(Kernighan和Plauger: Elements of Programming Style，1974年，是的，我有一份副本:-)。有时还会识别出额外的好规则。

除非在非常罕见的情况下(如故意混淆)，代码应该遵循这些“已建立的良好规则”，与它们是否是MISRA-XXXX的一部分无关。而且，如果发现了新的好规则，请确保人们开始遵守它。您甚至可以决定将这个新的好规则应用于现有的代码，但这更多地是一个管理决定，因为涉及的风险。

仅仅因为它不是MISRA-XXXX的一部分而不遵循一个好的规则是没有意义的。同样，仅仅因为它是MISRA-XXXX的一部分而遵循一条糟糕的规则也是没有意义的。(在MISRA-C-2004中，据说他们已经从MISRA-1998中删除了16条规则，因为“它们没有意义”--希望一些开发人员已经注意到了，并且没有应用它们。而且，正如Lundin提到的那样，在MISRA-2012中，一些“奇怪的规则”已经被删除)。

但是，请注意，对于几乎每条规则，其轻率的应用在某些情况下甚至会降低它通常支持的质量标准。

除了那些普遍适用的规则之外，还有一些规则只有在您的代码有特定的质量标准时才相关。让事情变得复杂的是，在大多数项目中，对于代码的不同部分，各种质量标准具有不同的相关性。

中断服务例程的

• 性能比软件的大多数其他部分更为关键。因此，折衷了wrt。
• 一些软件部件被设计成可以在不同环境之间移植，但通常是通过引入适配器/包装器来实现的，然后这些适配器/包装器是特定于特定环境的。因此，适配器本身甚至不应该是可移植的。

除了上述“已建立的良好规则”之外，一组固定的编码规则因此不能很好地适用于典型软件的所有部分。因此，对于软件的每个部分，首先确定哪些质量标准与该部分相关。然后，适当地应用那些真正支持特定质量标准的模式、原则和规则。

但是，米斯拉呢？MISRA规则旨在支持质量标准，如通过可分析性(例如，禁止递归和动态内存管理)的正确性，可移植性(例如，汇编代码的隔离)。也就是说，对于这些特定质量标准不相关的软件部件，相应的MISRA规则不会带来任何好处。不幸的是，MISRA没有软件架构的概念，不同的部分有不同的质量标准。

虽然许多规则在MISRA版本中得到了改进，但仍然有许多规则比必要的更严格(例如，“在//注释中没有/*，反之亦然”-为什么？)以及试图避免(不太可能的)错误的规则，这些错误可能会引入问题，而不是解决问题(例如，“不能重用任何名称，甚至不能在不同的本地范围内”)。这是我给你的小贴士:如果你a)真的想让你的规则检查器找到所有的bug，b)不介意得到数量荒谬的警告和高误报率，这一条规则/检查器会为你做所有的事情：“警告:检测到代码行：”。

最后，MISRA是在假设C(特别是它的算法)太难理解的情况下开发的。MISRA在C语言之上开发了自己的算法，相信开发人员应该学习MISRA算法，然后就可以在不了解C算法的情况下脱颖而出。显然，这并不成功，因为MISRA-2004模型(“底层类型”)被MISRA-2012中的另一个模型(“基本类型”)所取代。因此，如果您的团队很好地理解了C，并且使用了一个很好的静态分析工具(甚至是几个)，能够用C的算法识别出有问题的场景，那么MISRA方法可能不适合您。

DR:遵循标准的最佳实践，应用已建立的良好规则。为您的架构的不同部分确定特定的质量标准。对于每个部分，应用适合该部分的模式、原则和规则。在应用规则之前，请先了解规则。不要应用愚蠢的规则。使用良好的静态代码分析。确保你的团队理解C语言。

Answer 3

就像你的编译器套件或开发环境，和/或你的静态分析工具一样，适当的版本应该在项目现场决定，因为它可能很难在以后改变！

如果您正在从头开始一个项目，那么我建议采用MISRA C:2012 --也许也采用新的(2016年4月) MISRA Compliance的指导

新的合规性指南还提供了如何对待采用的代码(即预先存在的或导入的代码)的建议。

已开发到较早版本的现有项目应继续使用该较早版本...除非有一个很好的商业案例来改变。更改会导致一些返工！