第3章驼峰命名法 vs 下划线命名法

第3章：驼峰命名法 vs 下划线命名法

这一章我们来聊聊命名风格。说实话，我见过不少团队因为命名风格吵得不可开交。小驼峰、大驼峰、全小写下划线，到底选哪个？

先别急着站队。我做了15年嵌入式开发，三种风格都用过，踩过的坑比你们想象的多。今天我把它们掰开揉碎了讲清楚。

3.1 三种风格长什么样

先看个直观的例子。假设我们要定义一个变量，表示「温度传感器的数据缓冲区大小」。

// 小驼峰（camelCase）
int tempSensorBufSize;

// 大驼峰（PascalCase）
int TempSensorBufSize;

// 全小写下划线（snake_case）
int temp_sensor_buf_size;

嗯，一眼看过去，差别主要在大小写和下划线上。但实际用起来，区别可大了。

3.2 小驼峰：C语言里的「外来户」

小驼峰在Java、JavaScript里很常见。但在C语言里，我个人不太推荐。

为什么？因为C语言标准库和Linux内核都用下划线风格。你想想看，代码里混着两种风格，多别扭。

// 混搭风格，看着就难受
int readSensorData(int sensorId, char* dataBuf);

我在一个项目里见过这种写法。当时有个同事从Java转过来，坚持用小驼峰。结果代码review时，大家光改命名就花了两天。

避坑指南： 我曾经在一个RTOS项目里混用了小驼峰和下划线，结果调试时经常把变量名写错。编译器报错还好，最怕的是逻辑错误——变量名看起来像但实际不同，排查起来真要命。

3.3 大驼峰：适合类型定义，不适合变量

大驼峰在C++里用得比较多，比如类名。但在C语言里，我建议只用在类型定义上。

// 大驼峰用于类型定义，清晰明了
typedef struct {
    int id;
    char name[32];
} SensorConfig;

// 但变量也用大驼峰，就有点过了
int SensorCount;  // 不推荐
int sensorCount;  // 小驼峰也不推荐
int sensor_count; // 这才是C的风格

说白了，大驼峰在C语言里有点「用力过猛」。变量名不需要那么隆重，简洁清晰就好。

3.4 全小写下划线：嵌入式C的「正统」

我个人强烈推荐全小写下划线风格。原因有三：

兼容性好：Linux内核、FreeRTOS、uC/OS都这么用
可读性强：下划线天然分隔单词，一眼就能看出含义
避免混淆：全小写不会和宏定义（全大写）搞混

// 推荐风格
#define MAX_SENSOR_COUNT  8

int sensor_count;
int current_temperature;
void read_sensor_data(int sensor_id, uint8_t* buffer);

小技巧： 变量名长度控制在20个字符以内。太长了容易写错，太短了含义不清。比如 temp_sensor_buf_size 就比 tsbs 好得多。

3.5 三种风格对比表

风格	示例	推荐场景	不推荐场景
小驼峰	tempSensorBuf	函数参数、局部变量（少量）	全局变量、结构体成员
大驼峰	TempSensorBuf	类型定义（typedef、struct）	普通变量、函数名
全小写下划线	temp_sensor_buf	全局变量、函数、宏（全大写）	无（嵌入式C首选）

3.6 给嵌入式团队的推荐

如果你在组建新团队，或者想统一代码风格，我建议这样做：

变量和函数：全小写下划线
类型定义：大驼峰
宏定义：全大写加下划线
枚举常量：全大写加下划线

// 完整的命名示例
#define TIMEOUT_MS  1000

typedef enum {
    STATE_IDLE,
    STATE_RUNNING,
    STATE_ERROR
} system_state_t;

typedef struct {
    int sensor_id;
    int temperature;
    int humidity;
} sensor_data_t;

int read_sensor_data(sensor_data_t* data);
void process_sensor_data(void);

核心原则： 一致性比风格本身更重要。哪怕你选了小驼峰，只要全团队统一，也比混用强。但我还是那句话——嵌入式C，全小写下划线是最稳妥的选择。

好了，这一章就到这里。下一章我们聊聊变量作用域的命名技巧，那可是个容易踩坑的地方。

📚 课程目录