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

我一直在想，一个项目/团队/公司如何选择或有资格选择要遵循的特定指南，如MISRA 1998/2004/2012？一个人应该如何知道并决定哪一条指导方针将足以证明一个项目的成本、时间和质量

---

我知道他的问题有点直截了当，但任何答案都将受到欢迎

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

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

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

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

这里的关键是，每一家生产软件的半专业公司都需要某种编码规则，以禁止不良行为。一些公司倾向于过分关注一些不重要的风格细节，比如在哪里放置{，什么时候应该关注真正提高软件质量的东西，比如我们应该避免编写宏这样的函数

编码规则应该与开发例程相结合。为一个项目实现MISRA-C没有多大意义。建立和运行MISRA-C需要做大量的工作

非常重要的是，你至少有一位，最好是几位有多年经验的C级老手，负责编码规则。他们需要阅读MISRA文档中的每一个肮脏细节，并决定哪些规则对公司实施是有意义的。有些规则远非琐碎易懂。而不是简单易懂的所有这些在任何情况下都是有意义的。如果你的开发团队仅仅由初学者或有中级经验的程序员组成，而你决定完全遵循MISRA，那么结果会很糟糕。你至少需要一名经验丰富的程序员，他们有足够的知识来决定哪些规则需要遵循，哪些规则需要偏离

---

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

就像编译器套件或开发环境，和/或静态分析工具一样，应该在n-项目集，因为以后可能很难更改

如果您是从零开始一个项目，那么我建议采用MISRA C:2012，或许也采用2016年4月的新指南

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

---

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

编写代码时，应确保其具有某些期望的属性质量标准。一些质量标准实际上总是期望的，李ke正确性、可读性、可维护性—即使在这里也有例外，例如，如果您为模糊c竞赛或秘密c竞赛编写代码。其他质量标准仅与某些项目或组织相关，例如可移植到16位机器

一个制定良好的编码规则通常支持一个或多个质量标准。但是，它可能与其他标准冲突。有大量已建立的编码规则支持通常所需的质量标准，但对其他标准没有显著的负面影响。其中许多规则很久以前就已确定nighan和Plauger：《编程风格的元素》，1974年，是的，我有一份副本：-。有时会发现其他好的规则

除非在非常罕见的情况下，例如，故意混淆代码应遵循这些已建立的良好规则，与它们是否属于MISRA-XXXX无关。并且，如果发现新的良好规则，请确保人们开始遵循它。您甚至可以决定应用 将这个新的好规则应用到已有的代码中，但这更多的是管理层的决策，因为它涉及到风险

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

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

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

对于中断服务，例程的性能比软件的大多数其他部分更为关键。因此，妥协wrt。将制定其他质量标准。 一些软件部件被设计为可在不同环境之间移植，但通常是通过引入适配器/包装器来实现的，这些适配器/包装器是特定于特定环境的。因此，适配器本身甚至不打算是便携式的。 除上述已建立的良好规则外，一组固定的编码规则不能很好地适用于典型软件的所有部分。因此，对于软件的每个部分，首先确定与该部分相关的质量标准。然后，适当地应用那些真正支持这些特定质量标准的模式、原则和规则

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

尽管许多规则比MISRA版本有所改进，但仍有许多规则比必要的更为严格，例如注释中的no/*和注释中的no/*以及注释中的no/*等等，为什么？以及试图避免不太可能的错误的规则，这些错误可能会导致问题而不是解决问题，例如，任何名称都不能重复使用，即使在不同的局部范围内也不能重复使用。这里是我给你的提示：如果你真的希望你的规则检查器能找到所有的bug，而你不介意得到大量的错误率很高的警告，那么这个规则/检查器可以帮你做到这一切：警告：检测到的代码行：

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

---

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

我投票将这个问题作为离题题来结束，因为它是关于高级软件开发的，而不是编程。