【读书笔记】代码整洁之道

原文地址：http://www.hoohack.me/2016/03/23/code-clean-read-note

第一章 整洁代码

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

整洁的代码只做好一件事。

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

要想干得快，要想快点做完，要想轻松写代码，先让代码易读吧。

让每次签入时，代码都比签出时干净。

第二章，有意义的命名

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这样类似的短语。

第三章 函数

函数的第一规则是要短小，第二规则是还要更短小。

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

函数应该做一件事，做好这件事，只做这一件事。

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

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

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

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

把指令和询问分隔开来。

别重复自己。

如何做到：先想些什么就写什么，然后再打磨它。

第四章 注释

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

注释会撒谎，因为修改代码后并不会让注释随之变动。

注释不会美化糟糕的代码。

与其花时间美化代码，不如花时间清洁代码。

好注释：

1、法律信息

2、提供信息的注释

3、对意图的注释

4、阐释

5、警示

6、TODO

7、放大：放大某种看起来不合理之物的重要性

8、公共API中的javadoc

坏注释：

1、喃喃自语

2、多余的注释

3、误导性注释

4、循规式注释

5、日志式注释

6、废话注释

7、可怕的废话

8、能用函数或变量时就别用注释

9、位置标记

10、括号后面的注释

11、归属和署名

12、注释掉的代码（别这么干）

13、html注释

14、非本地信息

15、信息过多

16、不明显的联系

17、函数头

18、非公共代码中的javadoc

第五章 格式

代码格式很重要，关乎沟通。

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

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

四则运算时，运算级较高的符号可以不用空格隔开。

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

第六章 对象和数据结构

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

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

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

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

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

C
由f创建的对象

由C的实体变量持有的对象

即：方法不应调用由任何函数返回的对象的方法。

第七章 错误处理

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

使用不可控异常

给出异常发生的环境说明。

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

依调用者需要定义异常类。

定义常规流程。

别返回null值。

别传递null值。

第九章 单元测试

TDD三定律

1、在编写不能通过的单元测试前，不可编写生产代码。

2、只可编写刚好无法通过的单元测试，不能编译也不算通过。

3、只可编写刚好足以通过当前失败测试的生产代码。

保持测试整洁。

脏测试等同于没测试。

测试代码和生产代码一样重要。

整洁的测试三要素：可读性，可读性和可读性。

每个测试一个断言。

每个测试只测试一个概念。

F.I.R.S.T.

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

第十章 类

类应该短小。

用权责衡量类的大小。

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

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

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

内聚：如果一个类中的每个变量都被每个方法所使用，则该类具有最大的内聚性。

第十一章 系统

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

使用工厂方法，让程序负责确定何时创建对象。

AOP 切面编程

第十二章 迭进

简单设计四条规则：

运行所有测试；

不可重复；

表达了程序员的意图；

尽可能减少类和方法的数量。

极其雷同的代码就是重复。

要想实现大规模复用，必须理解如何实现小规模复用。

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

第十三章 并发编程

对象是过程的抽象，线程是调度的抽象。

并发是一种解耦策略，帮助我们把做什么（目的）和何时（时间）做分解开。

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

正确的并发是复杂的，即便对于简单的问题也是如此。

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

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

并发防御原则：

1、SRP，分离并发相关代码和其他代码。

2、推论：限制数据作用域。

3、推论：使用数据复本，避免共享数据的好方法之一就是一开始就避免共享数据。

4、推论：线程应尽可能独立。尝试将数据分解到可独立线程（可能在不同处理器上）操作的独立子集。

并发执行模型

生产者－消费者

读者－作者

宴席哲学家

学习这些基础算法，理解其解决方案。

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

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

总结

看了这本书，得到了很多新的指导，建议。这确实是一本好书，作者表达很清晰，说明白了该怎么做。虽然知道了，但是还是得要根据当中的理论多去实践才能体会当中的精髓。