1. 命名规范总则：为什么需要统一的命名规范？
说实话，我见过太多因为命名混乱导致的惨案了。
有一次，我接手一个老项目。打开代码一看，同一个变量，有人叫 pData，有人叫 data_ptr，还有人叫 m_data。你猜怎么着？这三个其实是同一个东西。调试了整整两天，最后发现是命名不一致导致的理解偏差。嗯，从那以后，我对命名规范这件事就特别较真。
为什么非要统一命名？
说白了，命名规范不是为了好看，是为了保命。嵌入式开发里，代码的可读性直接决定了你的调试效率。我总结了几点：
- 降低认知负担：看到名字就知道它是什么、干什么用。不用每次都得翻定义。
- 减少沟通成本：团队里大家写出来的代码风格一致，互相 review 的时候不会因为命名吵起来。
- 避免低级错误：变量名和函数名混淆？我见过有人把
i和j搞混，结果循环跑飞了。 - 方便工具分析：静态检查工具、代码搜索工具，对规范的命名更友好。
核心原则：命名要自解释。好的命名，不需要注释也能看懂。坏的命名，写再多注释也是白搭。
三种主流命名风格对比
市面上常见的命名风格，其实就三种。我一个个说。
1. 匈牙利命名法
这个老古董了。变量名前面加类型前缀，比如 iCount（int 类型）、pBuffer（指针类型）。Windows 时代的产物。
我个人不太推荐在嵌入式 C 里用。为什么？因为现代 IDE 都能直接显示类型了，你写个前缀反而啰嗦。而且，如果你改了变量类型，还得改名字，麻烦不麻烦？
避坑指南：我曾经在一个项目里看到有人用 ulData 表示 unsigned long，后来需求变了，改成 int，结果名字没改。新同事接手时以为还是 unsigned long，直接溢出。你说冤不冤？
2. 驼峰命名法
这个大家应该很熟悉。首字母小写，后面每个单词首字母大写，比如 getDataLength、setMotorSpeed。
优点是紧凑、好读。缺点嘛，在嵌入式里，有时候宏定义和变量名容易混淆。而且，有些老派的嵌入式工程师觉得驼峰太「软」，不够硬核。
我个人习惯：函数名用驼峰，变量名用下划线。这样一眼就能区分。
3. 下划线命名法
全小写，单词之间用下划线隔开，比如 get_data_length、motor_speed。Linux 内核和很多嵌入式 RTOS 都这么用。
说实话，这是我最推荐嵌入式 C 用的风格。原因很简单：
- 全小写，不用纠结大小写问题
- 下划线分隔，可读性高
- 和标准库风格一致（想想
strcpy、memcpy）
到底选哪个？
你想想看，嵌入式 C 代码最怕什么？最怕花里胡哨。我们追求的是稳定、可维护。所以我的建议是：
| 场景 | 推荐风格 | 示例 |
|---|---|---|
| 变量名 | 下划线命名法 | adc_value、timer_count |
| 函数名 | 下划线命名法 | uart_send_byte、gpio_set_level |
| 宏定义 | 全大写 + 下划线 | BUFFER_SIZE、GPIO_PIN_5 |
| 类型定义 | 下划线 + _t 后缀 | motor_config_t、uart_handle_t |
小技巧：如果你团队里有人坚持用驼峰，也不是不行。但一定要统一。最怕的是「混搭风」——同一个文件里，一半驼峰一半下划线。那才是真正的灾难。
我个人的命名铁律
做了这么多年嵌入式，我总结了几条铁律，分享给你：
- 不要用拼音：
shebei_zhuangtai这种东西，看着就头疼。英文不好可以查词典，别偷懒。 - 不要用单个字母：除了循环变量
i、j，其他情况尽量别用。你写的a，三个月后你自己都看不懂。 - 不要用缩写：除非是行业通用缩写（比如
ADC、PWM），否则老老实实写全称。cnt不如count，cfg不如config。 - 不要用否定命名：
is_not_ready这种，逻辑上容易搞混。用is_ready，然后取反。
嗯，大概就这些。命名规范这件事，说大不大，说小不小。但你要知道，好的代码是写给人看的，顺便给机器执行。命名规范，就是让「人」这部分更顺畅。
下一节，我们聊聊具体的变量命名规则。到时候我会拿几个真实项目里的坑，给你掰扯掰扯。