代码规范——预编译指令顶格写

最新推荐文章于 2026-01-06 15:27:22 发布

原创最新推荐文章于 2026-01-06 15:27:22 发布 · 468 阅读

7 ·

CC 4.0 BY-SA版权

文章标签：

#代码规范

代码规范专栏收录该内容

3 篇文章

订阅专栏

如下为例的很多官方库函数中，很多预编译指令（#include #ifdef ）都是顶格编写的，那预编译指令为什么要顶格写呢？为什么他们在多个#ifdef之间嵌套时也有没有进行缩进呢？

#if defined(USE_HSE_BYPASS)
      if (pllsource != 0)
      {
        /* HSE used as PLL clock source */
        pllvco = (HSE_BYPASS_INPUT_FREQUENCY / pllm) * ((RCC->PLLCFGR & RCC_PLLCFGR_PLLN) >> 6);
      }  		
#else  
      if (pllsource == 0)
      {
        /* HSI used as PLL clock source */
        pllvco = (HSI_VALUE / pllm) * ((RCC->PLLCFGR & RCC_PLLCFGR_PLLN) >> 6);
      }  
#endif /* USE_HSE_BYPASS */

其中主要原因包含以下几点

历史管理与语言规范

部分编译器认定预编译指令需要以#开头，且#为本行的第一个非空字符，编译器会严格检查，部分编译器会忽略或者报警

区分预编译指令和逻辑代码

诸如#if、#include之类的预编译指令是预处理阶段的指令，并不是实际运行的逻辑代码。
通过顶格写此类指令，可以在视觉上做到更好的区分，尤其是在预编译比较复杂的场景，帮助程序员快速确定哪里是预处理，哪里是实际的程序，

避免误导嵌套

预处理指令是在全局范围内有效的，其并不受逻辑类代码的规则所约束。
如果对预编译指令进行缩进，可能会误导开发者该指令受到了逻辑代码的影响，如果一不留神被逻辑代码带偏，真的是会付出血的代价啊。例如下面代码中，这里的 #define 实际上与 if 无关，但缩进会让人误以为它只在 if 块中生效。

if (condition) {
    #define DEBUG_MODE  // 错误的缩进！预处理指令不受 if 块影响
}

兼容性与工具支持

很多代码分析工具（例如静态分析工具、IDE高亮工具等）会依赖于预处理指令的特定格式来解析代码，顶格写预处理指令能在最大程度上防止工具误判。
某些编译器（尤其是旧版本）可能不支持缩进的预处理指令。

代码一致性

统一的顶格风格可以让代码更整洁，减少团队协作中的歧义。

很多预处理指令嵌套时如何处理？

可以使用注释和空行来区分预处理指令的层级

// 条件编译示例（用空行和注释区分层级）
#ifdef DEBUG_MODE
#define LOG(msg) printf("[DEBUG] %s\n", msg)

#ifdef VERBOSE_DEBUG
#define LOG_DETAIL(msg) printf("[VERBOSE] %s:%d - %s\n", __FILE__, __LINE__, msg)
#else
#define LOG_DETAIL(msg) // 空定义
#endif // VERBOSE_DEBUG 结束

#else
#define LOG(msg) // 空定义
#define LOG_DETAIL(msg) // 空定义
#endif // DEBUG_MODE 结束