1. 引言与规范总览
各位同学，咱们今天聊点实在的。
我做了十几年嵌入式开发，见过太多「能跑就行」的代码。说实话，每次看到那种代码，我心里都咯噔一下。为什么？因为这种代码，说白了就是给自己挖坑。
你可能会问：代码规范，真的那么重要吗？
嗯，咱们先看两个例子。
1.1 玩具代码长什么样？
先给你看一段代码。这是我刚入行时写的，现在回头看，脸都红。
void a()
{
int b;
b = 1;
if(b==1)
{
c();
}
else
{
d();
}
}这段代码能跑吗？能。但问题在哪？
- 函数名
a()，鬼知道它干嘛的 - 变量名
b，毫无意义 - 缩进混乱，看着就头疼
- 没有注释，三个月后我自己都看不懂
这就是典型的「玩具代码」。一个人写，一个人看，写完就扔。
1.2 工程化代码应该什么样？
再看这段。这是我后来在项目中重构的版本：
/* 检查传感器状态，异常时执行应急处理 */
static void check_sensor_status(void)
{
uint8_t sensor_value = 0;
sensor_value = read_sensor_data();
if (SENSOR_OK == sensor_value) {
execute_normal_routine();
} else {
execute_emergency_procedure();
}
}区别在哪？我跟你捋一捋：
| 对比项 | 玩具代码 | 工程化代码 |
|---|---|---|
| 命名 | 随意，a、b、c | 见名知意，check_sensor_status |
| 结构 | 混乱，无缩进 | 清晰，对齐规范 |
| 注释 | 没有 | 关键逻辑有说明 |
| 可维护性 | 极差 | 团队都能看懂 |
核心区别就一句话：玩具代码是写给机器看的，工程化代码是写给人看的。
1.3 为什么需要代码规范？
我在项目中遇到过一件事，印象特别深。
有一次，一个同事离职了，留下几千行代码。没有注释，变量名全是 temp1、temp2、flag。我们三个人花了两周才理清楚逻辑。那两周，天天加班到凌晨。
你想想看，如果当初有规范，会这样吗？
代码规范的价值，说白了就三点：
- 降低沟通成本：团队里每个人写的代码风格一致，不用猜
- 减少低级错误：比如命名规范能避免变量混淆，缩进规范能看清逻辑嵌套
- 提升维护效率：半年后改代码，自己也能快速上手
我的个人习惯：每次写代码前，先想清楚「三个月后的我，能不能一眼看懂这段代码？」如果答案是否定的，那就重写。
1.4 工程化思维的核心
工程化，不是让你写一堆花里胡哨的东西。它其实就一个原则：可读、可维护、可复用。
我曾经带过一个新人，他写的代码功能都对，但每次review我都得改半天。后来我问他：「你觉得代码是写给谁看的？」他想了想说：「给机器看的。」
我说：「错了。机器只关心能不能编译通过。代码是写给人看的，包括你自己。」
从那以后，他写代码前都会先画个流程图，理清逻辑再动手。嗯，进步很快。
1.5 本章知识体系
下面这张图，是我梳理的本章核心逻辑。你看一眼，心里就有数了：
注意：不要觉得规范是束缚。我见过太多人，一开始嫌麻烦不写规范，最后被自己写的代码坑得死去活来。规范不是限制你的创造力，而是保护你的时间。
好了，这一章就聊到这儿。记住一句话：代码规范，是对未来的自己负责。
可可精品资料库