整洁代码原则
版本: 1.0 | 更新: 2026-02-04
让代码如优美的散文,读之令人愉悦
概述
做了什么
提供一套整洁代码的核心原则和评判标准,帮助你写出可读、可维护、令人愉悦的代码。
为什么需要
- •糟糕的代码会拖慢开发速度,最终可能毁掉一个产品甚至一家公司
- •读代码的时间远超写代码的时间(比例超过 10:1)
- •代码会随时间腐坏,必须持续保持整洁
什么时候必须用
- •编写任何代码时
- •代码评审时
- •重构遗留代码时
- •培训新人时
何时使用此 Skill
| 场景 | 触发词 |
|---|---|
| 编写代码 | 怎么写好代码、代码规范、最佳实践 |
| 代码评审 | code review、代码审查、代码质量 |
| 重构代码 | 重构、改进代码、优化代码 |
| 技术债务 | 技术债、代码腐坏、遗留代码 |
核心理念
为什么代码永远重要
"代码确然是我们最终用来表达需求的那种语言。我们永远无法抛弃必要的精确性——所以代码永存。"
有人幻想代码会消失,需求可以直接生成程序。这永远不会发生。即便是 AI 时代,代码依然是精确表达需求的唯一方式。
糟糕代码的代价
| 阶段 | 后果 |
|---|---|
| 短期 | 开发速度变慢,每次修改都影响其他地方 |
| 中期 | 团队生产力趋近于零,加人也没用 |
| 长期 | 推倒重来,但新系统可能重蹈覆辙 |
勒布朗法则:稍后等于永不(Later equals never)
整洁代码的价值
"花时间保持代码整洁不但有关效率,还有关生存。"
大师们对整洁代码的定义
Bjarne Stroustrup(C++ 之父)
"我喜欢优雅和高效的代码。代码逻辑应当直截了当,叫缺陷难以隐藏;尽量减少依赖关系,使之便于维护;依据某种分层战略完善错误处理代码;性能调至最优,省得引诱别人做没规矩的优化,搞出一堆混乱来。整洁的代码只做好一件事。"
关键词:优雅、高效、直截了当、只做一件事
Grady Booch(UML 创始人之一)
"整洁的代码简单直接。整洁的代码如同优美的散文。整洁的代码从不隐藏设计者的意图,充满了干净利落的抽象和直截了当的控制语句。"
关键词:简单直接、如散文般可读、意图清晰
"老大" Dave Thomas(Eclipse 教父)
"整洁的代码应可由作者之外的开发者阅读和增补。它应当有单元测试和验收测试。它使用有意义的命名。它只提供一种而非多种做一件事的途径。它只有尽量少的依赖关系,而且要明确地定义和提供清晰、尽量少的 API。"
关键词:可读可增补、有测试、有意义的命名、尽量少
Michael Feathers(《修改代码的艺术》作者)
"整洁的代码总是看起来像是某位特别在意它的人写的。几乎没有改进的余地。代码作者什么都想到了,如果你企图改进它,总会回到原点,赞叹某人留给你的代码——全心投入的某人留下的代码。"
关键词:在意(Care)
Ron Jeffries(极限编程创始人之一)
简单代码,依其重要顺序:
- •能通过所有测试
- •没有重复代码
- •体现系统中的全部设计理念
- •包括尽量少的实体
关键词:无重复、有表达力、小规模抽象
Ward Cunningham(Wiki 发明者)
"如果每个例程都让你感到深合己意,那就是整洁代码。如果代码让编程语言看起来像是专为解决那个问题而存在,就可以称之为漂亮的代码。"
关键词:深合己意、语言为问题而生
整洁代码核心特征
一句话总结
| 特征 | 说明 |
|---|---|
| 只做一件事 | 每个函数、每个类、每个模块专注于一事 |
| 读起来像散文 | 代码意图清晰,不需要猜测 |
| 没有重复 | DRY 原则,重复是万恶之源 |
| 有测试 | 没有测试的代码不干净 |
| 尽量少 | 更少的依赖、更少的代码、更小的抽象 |
| 有人在意 | 看起来像是精心雕琢的作品 |
【强制】整洁代码规则
| 规则 | 说明 |
|---|---|
| 代码必须能通过所有测试 | 没有测试 = 不干净 |
| 代码必须无重复 | 重复超过 2 次必须抽取 |
| 代码必须表达意图 | 读者不需要猜你想干什么 |
| 代码必须尽量少 | 类、方法、函数数量最小化 |
为什么要写整洁代码
读代码 vs 写代码
"读与写花费时间的比例超过 10:1。写新代码时,我们一直在读旧代码。"
结论:要想写得快,先让代码易读。
破窗效应
"窗户破损了的建筑让人觉得似乎无人照管。于是别人也再不关心。他们放任窗户继续破损。最终自己也参加破坏活动。一扇破损的窗户开辟了大厦走向倾颓的道路。"
结论:糟糕的代码会引诱更多糟糕的代码。
态度问题
"程序员遵从不了解混乱风险的经理的意愿,也是不专业的做法。"
结论:
- •保持代码整洁是程序员的专业责任
- •不能把代码糟糕归咎于进度压力
- •制造混乱无助于赶上期限,只会拖慢速度
童子军军规
让营地比你来时更干净
应用到编程:
让代码比你签出时更干净
【推荐】每次提交的小改进
| 改进类型 | 示例 |
|---|---|
| 改好一个变量名 | d → elapsedTimeInDays |
| 拆分过长的函数 | 一个 100 行函数 → 几个 10-20 行函数 |
| 消除一点重复 | 抽取公共方法 |
| 清理嵌套 if | 使用卫语句、提前返回 |
| 添加一个注释 | 解释为什么,而非是什么 |
代码感(Code-Sense)
什么是代码感
"写整洁代码,需要遵循大量的小技巧,贯彻刻苦习得的'整洁感'。这种'代码感'就是关键所在。"
有无代码感的区别
| 无代码感 | 有代码感 |
|---|---|
| 看混乱是混乱,无处着手 | 从混乱中看出可能与变化 |
| 不知道怎么改进 | 知道最佳方案和改进路径 |
| 只能写新代码 | 能把烂代码变成好代码 |
如何培养代码感
- •多读好代码:阅读优秀开源项目
- •多写代码:练习,练习,再练习
- •多重构:把自己的烂代码改好
- •多评审:参与团队代码评审
- •多思考:每写一行代码都问"这是最好的表达方式吗?"
反例:糟糕代码的特征
【强制】禁止的代码特征
| 特征 | 后果 |
|---|---|
| 一个函数做多件事 | 难以理解、难以测试、难以复用 |
| 命名无意义 | 读者必须猜测意图 |
| 重复代码 | 修改时遗漏,行为不一致 |
| 嵌套太深 | 逻辑难以跟踪 |
| 没有测试 | 不敢重构,代码腐坏 |
| 注释解释"是什么" | 说明代码本身不够清晰 |
反例代码
// ❌ 反例 - 糟糕的代码
public void doStuff(int d) {
for (int i = 0; i < d; i++) {
// 处理
if (flag) {
if (x > 0) {
if (y > 0) {
// 做一些事
calc();
// 做另一些事
save();
// 做更多事
notify();
}
}
}
}
}
// ✅ 正例 - 整洁的代码
public void processOrders(int orderCount) {
for (int i = 0; i < orderCount; i++) {
processOrder(i);
}
}
private void processOrder(int orderIndex) {
if (!isOrderValid(orderIndex)) {
return;
}
calculateOrderTotal(orderIndex);
saveOrder(orderIndex);
notifyCustomer(orderIndex);
}
整洁代码 Checklist
编写代码时自查
| # | 检查项 | 通过 |
|---|---|---|
| 1 | 函数只做一件事吗? | ☐ |
| 2 | 命名能表达意图吗? | ☐ |
| 3 | 有重复代码吗? | ☐ |
| 4 | 有测试吗? | ☐ |
| 5 | 嵌套层级超过 2 层了吗? | ☐ |
| 6 | 函数超过 20 行了吗? | ☐ |
| 7 | 别人能看懂吗? | ☐ |
代码评审时检查
| # | 检查项 | 通过 |
|---|---|---|
| 1 | 代码意图清晰吗? | ☐ |
| 2 | 有没有更简单的实现? | ☐ |
| 3 | 符合团队规范吗? | ☐ |
| 4 | 测试覆盖了边界情况吗? | ☐ |
| 5 | 比之前的代码更干净了吗? | ☐ |
记忆锚点
| 原则 | 一句话 |
|---|---|
| 只做一件事 | 每个函数、每个类只专注于一事 |
| 如散文般可读 | 代码应该像故事一样流畅 |
| 无重复 | 重复是万恶之源 |
| 在意 | 像工匠一样在意每一行代码 |
| 童子军军规 | 让代码比你来时更干净 |
| 稍后等于永不 | 现在就整理,别说以后 |
终极问题
"你还得练,孩子,还得练!"
读书不能让你成为艺术家,只能告诉你工具和技巧。要写出整洁代码,唯有:
练习,练习,再练习!
禁则速查表
| ❌ 禁止 | ✅ 正确做法 | 原因 |
|---|---|---|
| 一个函数做多件事 | 拆分成多个小函数 | 提高可读性和复用性 |
| 无意义的命名 | 使用表达意图的名称 | 让代码自解释 |
| 复制粘贴代码 | 抽取公共函数 | 避免修改遗漏 |
| 深层嵌套 | 使用卫语句、提前返回 | 降低认知负担 |
| 不写测试 | 每个功能都有测试 | 保证代码可重构 |
| 说"以后再整理" | 现在就整理 | 稍后等于永不 |
| 屈服于进度压力写烂代码 | 坚持代码质量 | 烂代码只会让你更慢 |
参考资料
| 来源 | 说明 |
|---|---|
| 《Clean Code》Robert C. Martin | 整洁代码圣经 |
| 《重构》Martin Fowler | 改进代码的系统方法 |
| 《代码大全》Steve McConnell | 软件构建的百科全书 |
| 《程序员修炼之道》Hunt & Thomas | 从程序员到编程大师 |