头文件包含保护（Include Guard）的命名准则及相关疑问

这个问题问得很好！头文件包含保护的命名确实没有C语言语法层面的强制要求，但有一套行业通用的准则和避坑指南，核心目的都是为了避免宏名冲突，同时保证可读性，我来给你逐一解答疑问：

1. 核心准则：唯一性优先 #

包含保护的本质是用一个唯一的宏来标记头文件是否已经被包含过，所以不管你怎么命名，只要能确保这个宏名在整个项目（包括你可能链接的第三方库）里不会重复，就达到了核心目的。

为了降低冲突概率，很多开发者会给宏名加上项目/库的前缀，比如如果你的项目叫PhysicsEngine，那可以写成PHYSICSENGINE_SPHERE_H_，这样就很难和其他项目里的sphere.h的包含保护冲突了。

2. 与文件名关联是惯例，而非强制 #

你看到的SPHERE_H_对应sphere.h是非常常见的惯例——把文件名转为全大写，加上_H_后缀，这样别人看到宏名就能立刻对应到对应的头文件，可读性拉满。

但你完全可以用SPHERE_作为包含保护，只要能确保它不会和项目里的其他宏（比如某个函数名、常量名的大写形式）冲突就行。不过SPHERE_这种短名字冲突风险更高，比如万一有个源文件里定义了#define SPHERE_ 3.14，那你的头文件包含保护就彻底失效了，所以加_H_后缀其实是个很实用的保险手段。

3. 下划线的使用有避坑规则 #

下划线不是必需的，但使用时要注意C标准的保留规则：

• 禁止使用以下划线开头且后跟大写字母的宏名（比如_SPHERE_H），也禁止使用双下划线开头/结尾的宏名（比如__SPHERE_H__）——这些命名是保留给编译器和标准库使用的，如果你用了，可能会和系统定义的宏冲突，导致奇怪的编译错误。
• 中间的下划线是用来分隔单词的，比如MY_PROJECT_SPHERE_H，目的是让宏名更易读，避免写成MYPROJECTSPHEREH这种连在一起的难读名字。

举几个实际例子 #

• ✅ 规范且安全的写法：

  #ifndef SPHERE_H_
  #define SPHERE_H_
  // 头文件内容
  #endif // SPHERE_H_
  

• ✅ 带项目前缀的安全写法：

  #ifndef GAME_ENGINE_SPHERE_H
  #define GAME_ENGINE_SPHERE_H
  // 头文件内容
  #endif // GAME_ENGINE_SPHERE_H
  

• ❌ 不推荐的写法：

  #ifndef _SPHERE_H // 违反标准保留规则
  #define _SPHERE_H
  // ...
  #endif
  

  #ifndef SPHERE // 冲突风险极高
  #define SPHERE
  // ...
  #endif
  

总结一下：只要保证宏名唯一且不违反C标准的保留规则，你可以灵活选择命名方式，但遵循行业惯例（关联文件名、加后缀/前缀）能让你的代码更易读、更安全。

内容的提问来源于stack exchange，提问作者prr