AgentSkillsCN

clean-code-principles

整洁代码的核心原则与实践。涵盖代码质量、可读性、命名规范、函数设计等关键领域。在编写代码、进行代码评审或重构时,可随时使用此技能。

SKILL.md
--- frontmatter
name: clean-code-principles
description: 整洁代码核心原则与实践。涵盖代码质量、可读性、命名、函数设计等。当编写代码、代码评审或重构时使用。
metadata:
  author: skill-hub
  version: "1.0"
  compatibility: 所有编程语言
  reference: "《Clean Code》- Robert C. Martin (Uncle Bob)"

整洁代码原则

版本: 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(极限编程创始人之一)

简单代码,依其重要顺序:

  1. 能通过所有测试
  2. 没有重复代码
  3. 体现系统中的全部设计理念
  4. 包括尽量少的实体

关键词:无重复、有表达力、小规模抽象

Ward Cunningham(Wiki 发明者)

"如果每个例程都让你感到深合己意,那就是整洁代码。如果代码让编程语言看起来像是专为解决那个问题而存在,就可以称之为漂亮的代码。"

关键词:深合己意、语言为问题而生


整洁代码核心特征

一句话总结

特征说明
只做一件事每个函数、每个类、每个模块专注于一事
读起来像散文代码意图清晰,不需要猜测
没有重复DRY 原则,重复是万恶之源
有测试没有测试的代码不干净
尽量少更少的依赖、更少的代码、更小的抽象
有人在意看起来像是精心雕琢的作品

【强制】整洁代码规则

规则说明
代码必须能通过所有测试没有测试 = 不干净
代码必须无重复重复超过 2 次必须抽取
代码必须表达意图读者不需要猜你想干什么
代码必须尽量少类、方法、函数数量最小化

为什么要写整洁代码

读代码 vs 写代码

"读与写花费时间的比例超过 10:1。写新代码时,我们一直在读旧代码。"

结论:要想写得快,先让代码易读。

破窗效应

"窗户破损了的建筑让人觉得似乎无人照管。于是别人也再不关心。他们放任窗户继续破损。最终自己也参加破坏活动。一扇破损的窗户开辟了大厦走向倾颓的道路。"

结论:糟糕的代码会引诱更多糟糕的代码。

态度问题

"程序员遵从不了解混乱风险的经理的意愿,也是不专业的做法。"

结论

  • 保持代码整洁是程序员的专业责任
  • 不能把代码糟糕归咎于进度压力
  • 制造混乱无助于赶上期限,只会拖慢速度

童子军军规

让营地比你来时更干净

应用到编程:

让代码比你签出时更干净

【推荐】每次提交的小改进

改进类型示例
改好一个变量名delapsedTimeInDays
拆分过长的函数一个 100 行函数 → 几个 10-20 行函数
消除一点重复抽取公共方法
清理嵌套 if使用卫语句、提前返回
添加一个注释解释为什么,而非是什么

代码感(Code-Sense)

什么是代码感

"写整洁代码,需要遵循大量的小技巧,贯彻刻苦习得的'整洁感'。这种'代码感'就是关键所在。"

有无代码感的区别

无代码感有代码感
看混乱是混乱,无处着手从混乱中看出可能与变化
不知道怎么改进知道最佳方案和改进路径
只能写新代码能把烂代码变成好代码

如何培养代码感

  1. 多读好代码:阅读优秀开源项目
  2. 多写代码:练习,练习,再练习
  3. 多重构:把自己的烂代码改好
  4. 多评审:参与团队代码评审
  5. 多思考:每写一行代码都问"这是最好的表达方式吗?"

反例:糟糕代码的特征

【强制】禁止的代码特征

特征后果
一个函数做多件事难以理解、难以测试、难以复用
命名无意义读者必须猜测意图
重复代码修改时遗漏,行为不一致
嵌套太深逻辑难以跟踪
没有测试不敢重构,代码腐坏
注释解释"是什么"说明代码本身不够清晰

反例代码

java
// ❌ 反例 - 糟糕的代码
public void doStuff(int d) {
    for (int i = 0; i < d; i++) {
        // 处理
        if (flag) {
            if (x > 0) {
                if (y > 0) {
                    // 做一些事
                    calc();
                    // 做另一些事
                    save();
                    // 做更多事
                    notify();
                }
            }
        }
    }
}
java
// ✅ 正例 - 整洁的代码
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从程序员到编程大师