命名总则：为什么命名是嵌入式C的第一道防线？

说实话，我见过太多嵌入式项目，最后都栽在了命名上。

你可能觉得我在夸大其词。变量名嘛，不就是个代号？能跑就行。但我在一线摸爬滚打15年，可以负责任地告诉你：命名质量，直接决定了你代码的寿命。

今天咱们就从三个维度，把命名这件事彻底讲透。

一、可读性：代码是写给人看的

先问个问题：你写代码，到底是给谁看的？

很多人脱口而出：给机器看的。错了。机器只关心二进制，你写成a、b、c它照样跑。但人不行。人需要理解、需要维护、需要交接。

我有个习惯：每次打开一个源文件，如果3秒内看不懂变量含义，这个命名就是失败的。

举个例子：

// 糟糕的命名
int a;
int b;
int c;
void func1(void);
void func2(void);

你猜a、b、c是干什么的？猜不出来吧。我在项目中接手过这样的代码，当时真想顺着网线去找原作者。

改成这样：

// 清晰的命名
int temperature_celsius;
int pressure_kpa;
int flow_rate_lpm;
void read_sensor_data(void);
void calculate_average(void);

一目了然。温度、压力、流量，单位都写清楚了。函数名也告诉你它在干什么。

二、可维护性：命名是代码的地图

嵌入式项目有个特点：生命周期长。一个产品可能维护5年、10年。你写的代码，大概率会被别人改，甚至被未来的你自己改。

这时候，命名就是你的地图。

我建议采用匈牙利命名法的变体，在变量名中体现类型信息：

// 带类型前缀的命名
uint32_t u32_system_tick;
uint16_t u16_adc_value;
uint8_t u8_button_state;
bool b_is_motor_running;

为什么要加前缀？因为C语言没有强类型检查。你定义一个uint16_t，别人可能当uint32_t用。加上前缀，一眼就知道类型，避免隐式转换的坑。

还有作用域前缀：

// 全局变量加g_前缀
uint32_t g_system_tick;

// 静态变量加s_前缀
static uint16_t s_adc_value;

// 局部变量不加前缀
uint8_t temp_value;

这样，看到g_就知道是全局的，改的时候要小心。看到s_就知道是模块内部的，别乱动。

三、防错：命名是你的最后一道防线

嵌入式C有个特点：错误往往不会立即暴露。你写错一个变量名，编译器可能不报错，但运行时就会出问题。

命名能帮你防错吗？能。

看这个例子：

// 容易混淆的命名
int result1;
int result2;
int result3;

三个result，你分得清哪个是哪个吗？万一赋值错了，查bug查到哭。

改成这样：

// 防错命名
int adc_result;
int dac_result;
int pwm_result;

每个变量都有明确的归属，想混淆都难。

还有更狠的：用命名来约束操作。

// 只读变量加const
const uint32_t MAX_BUFFER_SIZE = 1024;

// 指针变量加p前缀
uint8_t* p_buffer;
uint8_t* const p_fixed_addr;

看到const，你就知道不能改。看到p_，你就知道这是个指针，操作时要小心空指针和越界。

四、命名规范速查表

类别	规范	示例	说明
全局变量	g_ + 类型 + 名称	g_u32_system_tick	全局可见，修改需谨慎
静态变量	s_ + 类型 + 名称	s_u16_adc_value	模块内部使用
局部变量	类型 + 名称	u8_temp	函数内部临时使用
常量	全大写 + 下划线	MAX_BUFFER_SIZE	不可修改
函数	动词 + 名词	read_sensor()	描述行为
指针	p_ + 类型 + 名称	p_u8_buffer	提醒指针操作

五、总结

命名这件事，说白了就是用最小的成本，换取最大的收益。

你多花10秒钟想个好名字，未来可能省下10小时的调试时间。这笔账，怎么算都划算。

记住：好的命名，是代码最好的文档。它不需要额外维护，不会过期，永远和代码同步。

嗯，这就是我为什么说，命名是嵌入式C的第一道防线。不是危言耸听，是血泪教训换来的经验。

下一章，咱们聊聊具体的命名规则，比如驼峰式、下划线式，到底该用哪种。到时候见。