C/C++ 命名规范：提升代码可读性的关键
在大型 C++ 项目中，代码的可读性往往比算法本身更影响长期开发效率。一个变量叫 bufsz 还是 audio_buffer_size，可能看起来只是风格差异，但在三个月后回看代码时，这种'微小'选择会直接决定你是轻松定位问题，还是陷入无尽的调试深渊。
真正高效的团队不靠记忆，而靠命名直觉工作。本文总结了一套经过实战验证的命名策略，既符合工业级工程标准，又能无缝融入现代 C++（尤其是模板、智能指针、RAII 等特性）的编码习惯。
核心原则：命名即契约
好的命名不是为了炫技，而是建立一种团队共识——看到某个标识符，就能大致推断出它的生命周期、作用域和职责。这背后有三个关键词：
- 描述性优先：宁可长一点，也不要让人猜。
- 一致性压倒一切：哪怕你个人不喜欢某种风格，只要项目定了就统一执行。
- 工具友好：命名要利于 IDE 自动补全、静态分析和文档生成。
举个真实例子：在情感控制模块重构中，我们将原本模糊的 ec_mode 改为 emotion_intensity_factor_，虽然多打了几个字，但新成员第一次阅读代码就能理解其含义，减少了沟通成本。
文件命名：从磁盘开始的一致性
头文件与源文件应全部使用小写 + 下划线分隔，保持跨平台兼容性（某些文件系统对大小写敏感）。例如：
prosody_analyzer.h prosody_analyzer.cpp model_loader_onnx.cc
避免使用缩写或编号：
❌ 不推荐：
pa.h mod2.c
如果涉及硬件抽象层或平台适配，可通过前缀区分上下文：
bsp_audio_interface.h // 板级支持包 platform_linux_utils.cc
类型命名：让用户定义类型脱颖而出
所有复合类型（类、结构体、联合体、枚举类、typedef）采用大驼峰命名法（PascalCase），这是识别自定义类型的最直观方式。
class EmotionAnalyzer; struct AudioFrameHeader; union SampleDataUnion; enum class VoiceStyle; using SampleRateType = int;
这些名字不仅语义清晰，还能被 Doxygen 或 Clangd 正确解析，生成高质量文档和跳转提示。
模板参数命名建议
模板参数也属于'类型'，因此同样遵循 PascalCase：
- 类型参数用有意义的名字：
typename ElementType而非typename T - 非类型参数使用 snake_case：
int buffer_size
这样可以让泛型代码更具可读性：
template<typename DataType, MaxSize> { ... };
