嵌入式开发：每个公司编码标准应包括的7个部分

开发公司编码标准对每个嵌入式开发人员绝对至关重要。编码标准告诉开发人员他们需要做的许多事情和不做的事情，以便编写清晰、可审查的软件，以尽可能少的缺陷达到业务所需的质量水平。我们将在今天的文章中探讨的七个标准。

1.范围

定义公司标准将涵盖的范围非常重要，但经常被忽视。范围告诉读者该标准计划涵盖的内容以及它适用于谁!该标准仅适用于编写微控制器应用程序的C开发人员，还是还包括编写Linux应用程序或从事Linux内核工作的开发人员?该标准是否仅适用于开发的新代码，还是该标准需要适用于遗留代码?它是否也涵盖第三方库代码?范围为标准的其余部分以及应该继续阅读然后实施它的人奠定了基础。

2.验证

第二个是关于如何验证标准的建议。有许多不同的方法可以验证编码标准。这些通常包括代码审查和静态代码分析的组合。一个好的标准应该使用工具自动验证，但这并不总是可能的。在建议开发人员验证标准的时间进行评论很有用，例如，作为持续集成过程的一部分，开发人员是否应该在提交代码之前验证标准?还是只在发布时?这些是公司开发过程中经常涉及的问题，可能会发生变化。

3.外部参考

诸如C之类的嵌入式编程语言已经存在了半个世纪，没有理由从头开始制定标准!所以公司编码标准的第三个应该是外部参考。例如，一家公司可能会参考MISRA-C或CERT-C等行业标准，然后列出嵌入式开发人员应该遵循哪些指令以及可以忽略哪些指令的期望。这些外部参考允许标准建立在行业已奠定的基础上，并可以简化制定公司标准所需的工作。

4.C风格指南

几乎每个开发人员都有自己的C代码样式。C风格指南部分可能是确保正在开发的代码库具有一致的外观和感觉的最重要部分。这是列出重要指导方针的部分，例如：

间距

括号放置

允许的C关键字

避免使用的C关键字

评论块的外观

命名约定

ETC

如果开发人员都坚持C风格，那么几乎不可能确定谁编写了代码，因为每个模块看起来都应该一样!

5.项目

我还发现，就项目的组织方式提出建议很有用。例如，本节可以讨论以下领域：

软件版本化

如何组织软件层和模块

推荐的硬件抽象层，例如 CMSIS

如何处理中断服务程序、堆栈、堆和内存管理

集成第三方组件的建议。

ETC

包括这些细节还可以确保团队工作的每个项目都是一致的，并且嵌入式开发人员可以轻松地从一个项目转移到下一个项目。

6.硬件/编译器特定功能

开发人员还需要一些建议来连接硬件和使用编译器。例如，本节可以概述是否可以使用#pragma，如果可以，允许使用哪些指令。(当然这是特定于编译器的，因此编译器的更改意味着标准的更改，因此外部参考文档可能更有意义)。本节还可以演示与硬件寄存器和中断接口的首选方法。例如，直接访问注册，通过指针机制访问或使用指针配置结构。与硬件和编译器相关的任何内容都将在此处记录。

7.附录

附录可以包含大量对开发人员很重要但不一定属于编码标准的其余部分的信息。例如，一个团队可能包含一个定义“术语表”的附录，以便公司的任何新开发人员都可以学习公司内部使用的术语，但不一定是行业公认的术语。跟踪此类信息可以确保编码人员所需的一切都在一个地方，这样他们就无需在需要参考时浪费时间寻找它。

结论

公司编码标准是每个嵌入式开发团队都应该拥有的重要文件，这些文档为项目的实施奠定了基础，并且可以极大地影响代码库的质量。如果你有一个编码标准，你应该至少每年审查一次，以确保它的指导仍然有意义，如果你没有编码标准，则可以首先使用此文章建议的部分作为标准文档的大纲，每月更新一次，直到你拥有完整记录的编码标准。