编写可阅读的代码，可阅读性，代码规范，个人成长，个人素养等

1. 编写可阅读的代码

2. 篇
• 代码即架构
• 软件成本 = 发成本 + 维护成本
• 艺术家的喜悦

3. 大纲
1. 是什么让代码变得更好
2. 基础层次的改进
3. 逻辑的改进
4. 代码组织的改进
5. 技艺的精进

4. 是什么让代码变得更好
• 可读性的衡量标准
• 代码越短越好么
• 价值观
Part I

5. 可读性的衡量标准
别人理解所需时间最小化

6. 代码越短越好么
原则上的奥卡姆剃刀
原则上的取舍平衡
VS

7. 价值观
代码可读性是优秀工程师的
追求目标

8. 大纲
1. 是什么让代码变得更好
2. 基础层次的改进
3. 逻辑的改进
4. 代码组织的改进
5. 技艺的精进

9. 基础层次的改进
• 命名的表现力
• 审美
• 注释的用法
Part II

10. 命名的表现力
• 选择专业的词
• 避免泛泛的词汇
• 避免有 义的名字
• 利用名字的约定规范传递含义
DEMO

11. 审 美

12. • 代码的排版源于杂志
• 用空行把代码 分成逻辑段落
• 在必要时使用合理的对⻬齐
• 选择一个有意义的顺序来保持一致
• 相 函数就近原则
• 规范的一致性有时比正 更重要
对齐 顺序留白 亲密
性

13. 注释的用法
• 能从代码本身推断出的事实
• 粉饰烂代码的拐杖式注释
• 站在读者的立场写注释
• 意料之外、总结、代码瑕疵等
DEMO

14. 大纲
1. 是什么让代码变得更好
2. 基础层次的改进
3. 逻辑的改进
4. 代码组织的改进
5. 技艺的精进

15. 逻辑的改进
• 控制流程的改进
• 表达式的改进
• 变量的改进
Part III

16. 控制流程的改进
• 语句的处理顺序
• 三目运算符精简
• 函数提前返回
• 少嵌套
关键思想 流程越自然越好，使读者不用停下来重读你的代码
DEMO

17. 表达式的改进
• 拆分超⻓长的表达式
• 使用解释变量
• 德摩根定律
• 禁止滥用短路逻辑
关键思想 化繁为简，看一眼表达式就能理解大致的意思
DEMO

18. 变量的改进
• 少无用变量
• 合理 分变量作用域
关键思想 定时重构，避免无用变量累积，最小范围原则

19. 大纲
1. 是什么让代码变得更好
2. 基础层次的改进
3. 逻辑的改进
4. 代码组织的改进
5. 技艺的精进

20. 代码组织的改进
• 代码的抽象与抽取
• 函数的坏味道
• 把自然语言变为代码
• 小即美
Part IV

21. 代码的抽象与提取
职责单一原则
类或模块应有且只有一条加以修改的理由，命名的期间就会审视类的权责

22. 代码的抽象与提取
迪米特法则
最少知识原则（Least Knowledge Principle 简写LKP），一个对象应
当对其他对象有尽可能少的了解，不和陌生人说话

23. 函数的坏味道
• 函数命名是否能解释函数的作用
• 函数的副作用
• 函数参数的膨胀
• 函数布尔参数的副作用
DEMO

24. 小即美
• 消除不必要的函数，避免过度设计
• 让项目保持小，子项目思维
• 大教堂与集市
关键思想 最好读的代码就是不写代码

25. 大纲
1. 是什么让代码变得更好
2. 基础层次的改进
3. 逻辑的改进
4. 代码组织的改进
5. 技艺的精进

26. 技艺的精进
• 编程素 的精进
• 软件工艺的精进
Part V

27. 编程素 的精进
• 谦虚大于聪明
• 建立良好的自我 发意识
• 在行动之前做分析和规
• 不断学习成功项目经验并不断试验
• 阅读文档规范，拒绝百度，跨越英文⻔门槛
• 与专业人士多交流
• 向更高更专业的人看⻬齐
• 跨界思维
• 有目的的坚持与积累
会翻墙！

28. 软件工艺的精进
• 工欲善其事，必先利其器
• 首先为人写程序，其次才是机器
• 深入语言，语法 -> 语义 -> 语用
• 用规范管理 杂度
• 有重构思维，不断迭代
• 管理 杂度思维

30. 荐书