编写可阅读的代码

开篇

• 代码即架构

• 软件成本 = 开发成本 + 维护成本

• 艺术家的喜悦

大纲1. 是什么让代码变得更好

2. 基础层次的改进

3. 逻辑的改进

4. 代码组织的改进

5. 技艺的精进

是什么让代码变得更好

• 可读性的衡量标准

• 代码越短越好么

• 价值观

Part I

可读性的衡量标准

别人理解所需时间最小化

代码越短越好么

原则上的奥卡姆剃刀

原则上的取舍平衡

VS

价值观

代码可读性是优秀工程师的追求目标



3. 逻辑的改进


5. 技艺的精进

基础层次的改进

• 命名的表现力

• 审美

• 注释的用法

Part II

命名的表现力

• 选择专业的词

• 避免泛泛的词汇

• 避免有歧义的名字

• 利用名字的约定规范传递含义

DEMO

审美

• 代码的排版源于杂志

• 用空行把代码划分成逻辑段落

• 在必要时使用合理的对⻬齐

• 选择一个有意义的顺序来保持一致

• 相关函数就近原则

• 规范的一致性有时比正确更重要

对齐顺序留白亲密性

注释的用法

• 能从代码本身推断出的事实

• 粉饰烂代码的拐杖式注释

• 站在读者的立场写注释

• 意料之外、总结、代码瑕疵等

DEMO



3. 逻辑的改进


5. 技艺的精进

逻辑的改进

• 控制流程的改进

• 表达式的改进

• 变量的改进

Part III

控制流程的改进

• 语句的处理顺序

• 三目运算符精简

• 函数提前返回

• 减少嵌套

关键思想流程越自然越好，使读者不用停下来重读你的代码

DEMO

表达式的改进

• 拆分超⻓长的表达式

• 使用解释变量

• 德摩根定律

• 禁止滥用短路逻辑

关键思想化繁为简，看一眼表达式就能理解大致的意思

DEMO

变量的改进

• 减少无用变量

• 合理划分变量作用域

关键思想定时重构，避免无用变量累积，最小范围原则



3. 逻辑的改进


5. 技艺的精进

代码组织的改进

• 代码的抽象与抽取

• 函数的坏味道

• 把自然语言变为代码

• 小即美

Part IV

代码的抽象与提取

职责单一原则

类或模块应有且只有一条加以修改的理由，命名的期间就会审视类的权责

代码的抽象与提取

迪米特法则

最少知识原则（Least Knowledge Principle 简写LKP），一个对象应当对其他对象有尽可能少的了解，不和陌生人说话

函数的坏味道

• 函数命名是否能解释函数的作用

• 函数的副作用

• 函数参数的膨胀

• 函数布尔参数的副作用

DEMO

小即美

• 消除不必要的函数，避免过度设计

• 让项目保持小，子项目思维

• 大教堂与集市

关键思想最好读的代码就是不写代码



3. 逻辑的改进


5. 技艺的精进

技艺的精进

• 编程素养的精进

• 软件工艺的精进

Part V

编程素养的精进• 谦虚大于聪明

• 建立良好的自我开发意识

• 在行动之前做分析和规划

• 不断学习成功项目经验并不断试验

• 阅读文档规范，拒绝百度，跨越英文⻔门槛

• 与专业人士多交流

• 向更高更专业的人看⻬齐

• 跨界思维

• 有目的的坚持与积累

会翻墙！

软件工艺的精进

• 工欲善其事，必先利其器

• 首先为人写程序，其次才是机器

• 深入语言，语法 -> 语义 -> 语用

• 用规范管理复杂度

• 有重构思维，不断迭代

• 管理复杂度思维

荐书

Technology