53、【OS】【Nuttx】编码规范解读（一）

背景

nuttx 源码工程目录下有个 CONTRIBUTING.md 文件，里面有一段话：

作为 nuttx 项目的参与者，应该遵循 nuttx 的编码规范要求，提交的代码将会被 Github 持续集成系统检测，不符合要求的代码，将会被门禁拦下，nuttx 编码规范参考 [NuttX C Coding Standard]

Nuttx 编码规范

检测工具

下面就来看下 nuttx 的编码规范要求：

这里 nuttx 提供了一个 nxstyle 编码风格的检测工具 checkpatch.sh , 位于 tools/ 目录下，用户可手动，或者通过 pre-commit 钩子函数在本地自动化部署检测机制，确保在每次提交之前，都能检测一遍编码风格是否符合 nuttx 要求

检测工具的使用方法如下：

提供了 -g （基于 commit 的检查）和 -f （基于文件的检查）

文件组织架构

文件扩展名

nuttx 是基于C语言的，所以源文件用 .c，头文件用 .h

文件头注释

所有的比如 C，C++，makefile，或脚本都应该遵循如下文件头原则：

• 相对路径：从项目的顶级目录到该文件的相对路径
• 可选描述：简要描述文件的内容（如果需要），限制为一行
• 空行：描述之后插入一个空行
• 版权声明：NuttX 标准 Apache 2.0 版权声明

分组，块注释

• 在源文件或头文件中，所有相似的组件应该被分组在一起
• 定义不应随意出现在文件中，而是将类似的定义放在一起，并在前面加上一个块注释标识该分组

块注释的格式要求：

• 由 /* 开始，后面跟一系列星号（*），延伸到行末第 78 列（块内的注释不能超过第 78 列）
• 分组名称从第 4 列开始，前面第 1 列有星号（*），第 0 列是空格
• 结尾行从第 1 列开始，后面跟星号（*）一直到第 78 列 */ 结束注释

示例如下

/***************************************************************************** Public Functions****************************************************************************/

组名称遵循顺序如下：

大文件和小文件的块注释的有些许不同：

• 大文件：即使某个分组是空的，也应该包含块注释，以提供重要的信息，表明该部分是预留的
• 小文件：可以省略一些块注释，以避免块注释比实际内容还要大的尴尬情况

头文件幂等性

• 头文件必须防止多次包含导致的重复定义问题；通过在文件顶部添加宏定义，确保即使头文件被多次包含，其内部定义也只会被处理一次
• 位置：预处理器条件逻辑应该放在文件头部，位于文件头注释和“包含的文件”块注释之间，规范的例子没体现出来，举例如下：

/***************************************************************************** nuttx/nuttx_arch.h* ....****************************************************************************/#ifndef __INCLUDE_NUTTX_ARCH_H
#define __INCLUDE_NUTTX_ARCH_H/***************************************************************************** Included Files****************************************************************************/#include <nuttx/config.h>
#include <stdio.h>
....

• 尽管文件顶部有预处理逻辑，但文件内的其他定义不要因此有缩进
• 预处理器宏名称根据头文件相对于顶级目录的完整路径形成，每个无效于宏定义的字符（比如 /）会被替换为下划线 _。比如，__INCLUDE_NUTTX_ARCH_H 对应于 include/nuttx/arch.h 文件