Skip to content

Latest commit

 

History

History
276 lines (157 loc) · 8.38 KB

《代码整洁之道》.md

File metadata and controls

276 lines (157 loc) · 8.38 KB

《代码整洁之道》

第一章 整洁代码

1、赶上期限的唯一方法:始终尽可能保持代码整洁

2、整洁的代码只做好一件事

3、整本书的主旨,不要重复代码,只做一件事,表达力,小规模抽象

4、要想干得快,要想快点做完,要想轻松写代码,先让代码易读吧

5、让每次签入时,代码都比签出时干净

第二章 有意义的命名

1、名副其实

如果名称需要注释来补充,那就不算是名副其实。

2、避免误导

别用 xxxList 来指称一组账号,除非它真的是 List 类型。(用 xxxGroup/bunchOfxxx/xxxs 代替更好)

3、做有意义的区分

不要使用数字区分变量 / 函数命名。如 a1,a2... 不要添加废话区分命名。如:ProductInfo 和 ProductData

4、使用读得出来的名称

比如日期:用 generationTimestamp,而不要使用 genymdhms。

5、使用可搜索的名称

单字母和数字常量很难搜出。使用宏或者变量命名这类数据。

6、避免使用编码

不必用前缀表示成员变量。

7、避免思维映射

8、类名

类名和对象应该是名词或名词短语。

9、方法名

方法名应该是动词或动词短语。

10、别扮可爱

11、每个概念对应一个词

12、别用双关语

避免将同一个单词用于不同目的。

13、使用解决方案领域名称

尽可能使用 IT 类术语

14、使用源自所涉问题领域的名称

15、使用有意义的语境

如:使用 addrState 代替 state

16、不要添加没用的语境

如:不要用 GSD 代替 GasStationDeluxe 这样类似的短语。

第三章 函数

1、函数的第一规则是要短小,第二规则是还要更短小

2、函数的缩进层数不该多于一层或两层

3、函数应该做一件事,做好这件事,只做这一件事

4、要判断函数是否不止做了一件事,看是否能再拆出一个函数,该函数不仅是单纯地重新诠释其实现

5、函数参数,最理想的参数是 0, 其次是 1, 再次是 2. 尽量避免 3 个。有足够特殊的理由才能用 3 个以上函数

6、如果函数看起来需要两个,三个或三个以上参数,就说明其中一些参数应该封装成类了

7、函数不应有副作用,如,检查密码的函数不应该有初始化 Session 的步骤

8、把指令和询问分隔开来

9、别重复自己

10、如何做到:先想些什么就写什么,然后再打磨它

第四章 注释

1、注释的恰当用法是弥补我们在用代码表达意图时遭遇的失败

2、注释会撒谎,因为修改代码后并不会让注释随之变动

3、注释不会美化糟糕的代码

4、与其花时间美化代码,不如花时间清洁代码

好注释

  • 法律信息
  • 提供信息的注释
  • 对意图的注释
  • 阐释
  • 警示
  • TODO
  • 放大:放大某种看起来不合理之物的重要性
  • 公共 API 中的 javadoc

坏注释

  • 喃喃自语
  • 多余的注释
  • 误导性注释
  • 循规式注释
  • 日志式注释
  • 废话注释
  • 可怕的废话
  • 能用函数或变量时就别用注释
  • 位置标记
  • 括号后面的注释
  • 归属和署名
  • 注释掉的代码(别这么干)
  • html 注释
  • 非本地信息
  • 信息过多
  • 不明显的联系
  • 函数头
  • 非公共代码中的 javadoc

第五章 格式

1、代码格式很重要,关乎沟通

2、实体变量应该在类的顶部声明

3、相关函数。若某个函数调用了另一个,就应该把它们放到一起。而且调用着应该尽可能放在被调用着上面

4、四则运算时,运算级较高的符号可以不用空格隔开

5、每个程序员都有自己喜欢的格式规则,但如果在一个团队中工作,就是团队说了算

第六章 对象和数据结构

1、隐藏实现并非只是变量之间放上一个函数层那么简单。隐藏实现关乎抽象。类并不简单地用取值器和赋值器将变量推向外间,而是暴露抽象接口,以便用户无需了解数据的实现便能操作数据本体

2、要以最好的方式呈现某个对象包含的数据,需要做严肃的思考

3、过程式代码便于在不改动既有函数的前提下添加新类

4、得墨耳律:模块不应了解它所操作对象的内部情形

例如:类 C 的 f 方法只应调用以下对象的方法

C 由 f 创建的对象
由 C 的实体变量持有的对象
即:方法不应调用由任何函数返回的对象的方法。

第七章 错误处理

1、使用异常而非返回码。 先写 try、catch、finally 语句

2、使用不可控异常

3、给出异常发生的环境说明

应创建信息充分的错误信息,并和异常一起传递出去。在消息中,包括失败的操作和失败的类型。如果你的应用程序由日志系统,传递足够的信息给 catch 块,并记录下来。

4、依调用者需要定义异常类

5、定义常规流程

6、别返回 null 值

7、别传递 null 值

第九章 单元测试

1、TDD 三定律

  1. 在编写不能通过的单元测试前,不可编写生产代码。
  2. 只可编写刚好无法通过的单元测试,不能编译也不算通过。
  3. 只可编写刚好足以通过当前失败测试的生产代码。

2、保持测试整洁

3、脏测试等同于没测试

4、测试代码和生产代码一样重要

5、整洁的测试三要素:可读性,可读性和可读性

6、每个测试一个断言

7、每个测试只测试一个概念

8、F.I.R.S.T

Fast(快速)、Independent(独立)、Repeatable(可重复)、Self-Validating(自足验证)、Timely(及时)

第十章 类

1、类应该短小

2、用权责衡量类的大小

3、如果无法为某个类命以精确的名称,这个类大概太长了

4、SRP,单一权责原则,类或模块应有且只有一条加以修改的理由

5、系统应该有许多短小的类而不是少量巨大的类组成。每个小雷封装一个权责,只有一个修改的原因,并与少数其他类一起协同达成期望的系统行为

6、内聚:如果一个类中的每个变量都被每个方法所使用,则该类具有最大的内聚性

第十一章 系统

1、将构造与使用分开的方法之一是将全部构造过程搬迁到 main 或被称之为 main 的模块中,设计系统的其他部分时,假设所有对象都已正确构造和设置

2、使用工厂方法,让程序负责确定何时创建对象

3、AOP 切面编程

第十二章 迭进

1、简单设计四条规则

  1. 运行所有测试;
  2. 不可重复;
  3. 表达了程序员的意图;
  4. 尽可能减少类和方法的数量。

2、极其雷同的代码就是重复

3、要想实现大规模复用,必须理解如何实现小规模复用

4、模板方法模式是一种移除高层级重复的通用技巧

第十三章 并发编程

1、对象是过程的抽象,线程是调度的抽象

2、并发是一种解耦策略,帮助我们把做什么(目的)和何时(时间)做分解开

3、并发会在性能和编写额外代码上增加一些开销

4、正确的并发是复杂的,即便对于简单的问题也是如此

5、并发缺陷并非总能重现,所以常被看做偶发事件而忽略,未被当作真的缺陷对待

6、并发常常需要对设计策略的根本性修改

7、并发防御原则

  • SRP,分离并发相关代码和其他代码。
  • 推论:限制数据作用域。
  • 推论:使用数据复本,避免共享数据的好方法之一就是一开始就避免共享数据。
  • 推论:线程应尽可能独立。尝试将数据分解到可独立线程(可能在不同处理器上)操作的独立子集。

8、并发执行模型

  • 生产者-消费者
  • 读者-作者
  • 宴席哲学家

9、学习这些基础算法,理解其解决方案

10、在你认为自己完成某个函数之前,确认自己理解了它是怎么工作的。通过全部测试还不够好。你必须知道解决方案是正确的。获得这种知识和理解的最好途径,往往是重构函数,得到某种整洁而足具表达力、清楚呈示如何工作的东西

11、用多态替代 If/Else 或 Switch/Case