选择指南：MISRA 1998 或 MISRA 2004 或 MISRA 2012？

Question

我一直想知道项目/团队/公司如何选择或有资格选择要遵循的特定指南，例如 MISRA 1998/2004/2012？应该如何知道并决定哪项准则足以（成本、时间和质量）来确定项目的资格？

（我知道他的问题有点生硬，但任何答案将不胜感激）

Answer 1

这通常是应用领域的要求。您将拥有规定使用编程语言的安全子集的安全标准。这一要求可以来自工业IEC 61508、汽车IEC 26262、航空航天DO-178等“SIL”标准。在此类关键任务系统中，您可能别无选择，只能使用 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：编程风格的元素，1974 年，是的，我有它的副本 :-)。有时会发现其他好的规则。

除非在极少数情况下（如故意混淆），代码应遵循这些“既定良好规则”，无论它们是否属于 MISRA-XXXX 的一部分。而且，如果发现了新的好规则，请确保人们开始遵循它。您甚至可以决定将这条新的良好规则应用于现有代码，但由于涉及风险，这更像是一项管理决策。

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

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

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

• 对于中断服务例程，性能比软件的大多数其他部分更为关键。因此，妥协wrt。将制定其他质量标准。
• 一些软件部件被设计成可在环境之间移植，但通常是通过引入特定于特定环境的适配器/包装器。因此，适配器本身甚至不具备便携性。

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

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

虽然许多规则比 MISRA 版本有所改进，但仍有许多比必要的更严格的规则（例如“在 // cmets 内没有 /*，反之亦然” - 为什么？）和试图避免的规则（不太可能）以可能引入问题而不是解决问题的方式出现的错误（例如，“不重用任何名称，即使在不同的本地范围内也不行”）。这是我给你的提示：如果你 a) 真的希望你的规则检查器找到所有错误，并且 b) 不介意收到大量具有高误报率的荒谬警告，那么这个规则/检查器可以做到这一切你：“警告：检测到代码行：”。

最后，MISRA 是在 C（尤其是它的算术）太难理解的假设下开发的。 MISRA 在 C 之上开发了自己的算术，认为开发人员应该学习 MISRA 算术，然后可以在不理解 C 算术的情况下摆脱困境。显然，这并没有成功，因为 MISRA-2004 模型（“基础类型”）在 MISRA-2012 中被另一个（“基本类型”）替换。因此，如果您的团队非常了解 C 并且使用了一个很好的静态分析工具（或什至几个），它能够通过 C 的算法识别有问题的场景，那么 MISRA 方法可能不适合您。

TL;DR：遵循标准的最佳实践，应用既定的良好规则。确定架构不同部分的特定质量标准。对于每个部分，应用适合该部分的模式、原则和规则。在应用它们之前了解规则。不要应用愚蠢的规则。使用良好的静态代码分析。确保您的团队了解 C。

Answer 3

就像您的编译器套件或开发环境，和/或您的静态分析工具一样，应在项目开始时确定适当的版本，因为以后可能很难更改！

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

新的合规指南还就如何处理采用的代码（即预先存在或导入的代码）提供了建议。

已开发到较早版本的现有项目应继续使用该较早版本...除非有良好的业务案例可进行更改。更改将导致一些返工！