摘要

细节之中自有天地，整洁成就卓越代码。
尽管糟糕的代码也能运行，但如果代码不整洁，会使整个开发团队泥足深陷，写得不好的代码每年都要耗费难以计数的时间和资源。然而这种情况并非无法避免。
阅读《代码整洁之道》需要你做些什么呢？你将阅读代码——大量代码。《代码整洁之道》促使你思考代码中何谓正确，何谓错误。更重要的是，《代码整洁之道》将促使你重新评估自己的专业价值观，以及对自己技艺的承诺。
从《代码整洁之道》中可以学到：好代码和糟糕的代码之间的区别：如何编写好代码，如何将糟糕的代码转化为好代码：如何创建好名称、好函数、好对象和好类；如何格式化代码以实现其可读性的优化：如何在不妨碍代码逻辑的前提下充分实现错误处理；如何进行单元测试和测试驱动开发。

代码整洁之道[Clean Code A Handbook of Agile Software Craftsmanship] 内容简介

软件质量，不但依赖于架构及项目管理，而且与代码质量紧密相关。这一点，无论是敏捷开发流派还是传统开发流派，都不得不承认。《代码整洁之道》提出一种观念：代码质量与其整洁度成正比。干净的代码，既在质量上较为可靠，也为后期维护、升级奠定了良好基础。作为编程领域的佼佼者，《代码整洁之道》作者给出了一系列行之有效的整洁代码操作实践。这些实践在《代码整洁之道》中体现为一条条规则(或称“启示”)，并辅以来自现实项目的正、反两面的范例。只要遵循这些规则，就能编写出干净的代码，从而有效提升代码质量。

《代码整洁之道》阅读对象为一切有志于改善代码质量的程序员及技术经理。书中介绍的规则均来自作者多年的实践经验，涵盖从命名到重构的多个编程方面，虽为一“家”之言，然诚有可资借鉴的价值。

代码整洁之道[Clean Code A Handbook of Agile Software Craftsmanship] 目录

第1章　整洁代码　1

1.1　要有代码　2

1.2　糟糕的代码　2

1.3　混乱的代价　3

1.3.1　华丽新设计　4

1.3.2　态度　4

1.3.3　迷题　5

1.3.4　整洁代码的艺术　5

1.3.5　什么是整洁代码　6

1.4　思想流派　10

1.5　我们是作者　11

1.6　童子军军规　12

1.7　前传与原则　12

1.8　小结　12

1.9　文献　13

第2章　有意义的命名　15

2.1　介绍　15

2.2　名副其实　16

2.3　避免误导　17

2.4　做有意义的区分　18

2.5　使用读得出来的名称　19

2.6　使用可搜索的名称　20

2.7　避免使用编码　21

2.7.1　匈牙利语标记法　21

2.7.2　成员前缀　21

2.7.3　接口和实现　22

2.8　避免思维映射　22

2.9　 类名　23

2.10　方法名　23

2.11　别扮可爱　23

2.12　每个概念对应一个词　24

2.13　别用双关语　24

2.14　使用解决方案领域名称　25

2.15　使用源自所涉问题领域的名称　25

2.16　添加有意义的语境　25

2.17　不要添加没用的语境　27

2.18　最后的话　27

第3章　函数　29

3.1　短小　32

3.2　只做一件事　33

3.3　每个函数一个抽象层级　34

3.4　switch语句　35

3.5　使用描述性的名称　36

3.6　函数参数　37

3.6.1　一元函数的普遍形式　38

3.6.2　标识参数　38

3.6.3　二元函数　38

3.6.4　三元函数　39

3.6.5　参数对象　39

3.6.6　参数列表　40

3.6.7　动词与关键字　40

3.7　无副作用　40

3.8　分隔指令与询问　42

3.9　使用异常替代返回错误码　42

3.9.1　抽离Try/Catch代码块　43

3.9.2　错误处理就是一件事　44

3.9.3　Error.java依赖磁铁　44

3.10　别重复自己　44

3.11　结构化编程　45

3.12　如何写出这样的函数　45

3.13　小结　45

3.14　SetupTeardownIncluder程序　46

3.15　文献　48

第4章　注释　49

4.1　注释不能美化糟糕的代码　50

4.2　用代码来阐述　51

4.3　好注释　51

4.3.1　法律信息　51

4.3.2　提供信息的注释　51

4.3.3　对意图的解释　52

4.3.4　阐释　53

4.3.5　警示　53

4.3.6　TODO注释　54

4.3.7　放大　54

4.3.8　公共API中的Javadoc　55

4.4　坏注释　55

4.4.1　喃喃自语　55

4.4.2　多余的注释　56

4.4.3　误导性注释　58

4.4.4　循规式注释　58

4.4.5　日志式注释　59

4.4.6　废话注释　59

4.4.7　可怕的废话　61

4.4.8　能用函数或变量时就别用注释　62

4.4.9　位置标记　62

4.4.10　括号后面的注释　62

4.4.11　归属与署名　63

4.4.12　注释掉的代码　63

4.4.13　HTML注释　64

4.4.14　非本地信息　64

4.4.15　信息过多　65

4.4.16　不明显的联系　65

4.4.17　函数头　66

4.4.18　非公共代码中的Javadoc　66

4.4.19　范例　66

4.5　文献　69

第5章　格式　71

5.1　格式的目的　72

5.2　垂直格式　72

5.2.1　向报纸学习　73

5.2.2　概念间垂直方向上的区隔　73

5.2.3　垂直方向上的靠近　74

5.2.4　垂直距离　75

5.2.5　垂直顺序　79

5.3　横向格式　79

5.3.1　水平方向上的区隔与靠近　80

5.3.2　水平对齐　81

5.3.3　缩进　82

5.3.4　空范围　84

5.4　团队规则　84

5.5　鲍勃大叔的格式规则　85

第6章　对象和数据结构　87

6.1　数据抽象　87

6.2　数据、对象的反对称性　89

6.3　得墨忒耳律　91

6.3.1　火车失事　91

6.3.2　混杂　92

6.3.3　隐藏结构　92

6.4　数据传送对象　93

6.5　小结　94

6.6　文献　94

第7章　错误处理　95

7.1　使用异常而非返回码　96

7.2　先写Try-Catch-Finally语句　97

7.3　使用不可控异常　98

7.4　给出异常发生的环境说明　99

7.5　依调用者需要定义异常类　99

7.6　定义常规流程　100

7.7　别返回null值　101

7.8　别传递null值　102

7.9　小结　103

7.10 文献　104

第8章　边界　105

8.1　使用第三方代码　106

8.2　浏览和学习边界　107

8.3　学习log4j　108

8.4　学习性测试的好处不只是免费　110

8.5　使用尚不存在的代码　110

8.6　整洁的边界　111

8.7　文献　112

第9章　单元测试　113

9.1　TDD三定律　114

9.2　保持测试整洁　115

9.3　整洁的测试　116

9.3.1　面向特定领域的测试语言　118

9.3.2　双重标准　119

9.4　每个测试一个断言　121

9.5　F.I.R.S.T.　122

9.6　小结　123

9.7　文献　124

第10章　类　125

10.1　类的组织　126

10.2　类应该短小　126

10.2.1　单一权责原则　128

10.2.2　内聚　129

10.2.3　保持内聚性就会得到许多短小的类　130

10.3　为了修改而组织　136

10.4　文献　139

第11章　系统　141

11.1　如何建造一个城市　142

11.2　将系统的构造与使用分开　142

11.2.1　分解main　143

11.2.2　工厂　143

11.2.3　依赖注入　144

11.3　扩容　145

11.4　Java代理　148

11.5　纯Java AOP框架　150

11.6　AspectJ的方面　152

11.7　测试驱动系统架构　153

11.8　优化决策　154

11.9　明智使用添加了可论证价值的标准　154

11.10 系统需要领域特定语言　154

11.11 小结　155

11.12 文献　155

第12章　迭进　157

12.1　通过迭进设计达到整洁目的　157

12.2　简单设计规则1：运行所有测试　158

12.3　简单设计规则2～4：重构　158

12.4　不可重复　159

12.5　表达力　161

12.6　尽可能少的类和方法　162

12.7　小结　162

12.8　文献　162

第13章　并发编程　163

13.1　为什么要并发　164

13.2　挑战　165

13.3　并发防御原则　166

13.3.1　单一权责原则　166

13.3.2　推论：限制数据作用域　166

13.3.3　推论：使用数据复本　167

13.3.4　推论：线程应尽可能地独立　167

13.4　了解Java库　167

13.5　了解执行模型　168

13.5.1　生产者-消费者模型　169

13.5.2　读者-作者模型　169

13.5.3　宴席哲学家　169

13.6　警惕同步方法之间的依赖　169

13.7　保持同步区域微小　170

13.8　很难编写正确的关闭代码　170

13.9　测试线程代码　171

13.9.1　将伪失败看作可能的线程问题　171

13.9.2　先使非线程代码可工作　171

13.9.3　编写可插拔的线程代码　172

13.9.4　编写可调整的线程代码　172

13.9.5　运行多于处理器数量的线程　172

13.9.6　在不同平台上运行　172

13.9.7　装置试错代码　173

13.9.8　硬编码　173

13.9.9　自动化　174

13.10　小结　175

13.11　文献　175

第14章　逐步改进　176

14.1　Args的实现　177

14.2　Args：草稿　183

14.2.1　所以我暂停了　195

14.2.2　渐进　195

14.3　字符串参数　197

14.4　小结　234

第15章　JUnit内幕　235

15.1　JUnit框架　236

15.2　小结　249

第16章　重构SerialDate　251

16.1　首先，让它能工作　252

16.2　让它做对　254

16.3　小结　266

16.4　文献　267

第17章　味道与启发　269

17.1　注释　270

17.2　环境　271

17.3　函数　271

17.4　一般性问题　272

17.5　Java　288

17.6　名称　291

17.7　测试　294

17.8　小结　295

17.9　文献　296

附录A　并发编程II　297

A.1　客户端/服务器的例子　297

A.1.1　服务器　297

A.1.2　添加线程代码　298

A.1.3　观察服务器端　299

A.1.4　小结　301

A.2　执行的可能路径　301

A.2.1　路径数量　302

A.2.2　深入挖掘　303

A.2.3　小结　305

A.3　了解类库　305

A.3.1　Executor框架　305

A.3.2　非锁定的解决方案　306

A.3.3　非线程安全类　307

A.4　方法之间的依赖可能破坏并发代码　308

A.4.1　容忍错误　309

A.4.2　基于客户代码的锁定　309

A.4.3　基于服务端的锁定　311

A.5　提升吞吐量　312

A.5.1　单线程条件下的吞吐量　313

A.5.2　多线程条件下的吞吐量　313

A.6　死锁　314

A.6.1　互斥　315

A.6.2　上锁及等待　315

A.6.3　无抢先机制　315

A.6.4　循环等待　315

A.6.5　不互斥　316

A.6.6　不上锁及等待　316

A.6.7　满足抢先机制　317

A.6.8　不做循环等待　317

A.7　测试多线程代码　317

A.8　测试线程代码的工具支持　320

A.9　小结　320

A.10 教程：完整代码范例　321

A.10.1　客户端/服务器非线程代码　321

A.10.2　使用线程的客户端/服务器代码　324

附录B　org.jfree.date.SerialDate　327

结束语　389

代码整洁之道[Clean Code A Handbook of Agile Software Craftsmanship] 精彩文摘

这也意味着函数不应该大到足以容纳嵌套结构。所以，函数的缩进层级不该多于一层或两层。当然，这样的函数易于阅读和理解。代码清单3－1显然想做好几件事。它创建缓冲区、获取页面、搜索继承下来的页面、渲染路径、添加神秘的字符串、生成HTML，如此等等。代码清单3－1手忙脚乱。而代码清单3－3则只做一件简单的事。它将设置和拆解包纳到测试页面中。

过去30年以来，以下建议以不同形式一再出现：函数应该做一件事。做好这件事。只做这一件事。

问题在于很难知道那件该做的事是什么。

代码清单3.3只做了一件事，对吧？其实也很容易看作是三件事：（1）判断是否为测试页面；（2）如果是，则容纳进设置和分拆步骤；（3）渲染成HTML。如果函数只是做了该函数名下同一抽象层上的步骤，则函数还是只做了一件事。

编写函数毕竟是为了把大一些的概念（换言之，函数的名称）拆分为另一抽象层上的一系列步骤。

代码清单3.1明显包括了处于多个不同抽象层级的步骤。显然，它所做的不止一件事。即便是代码清单3-2也有两个抽象层，这已被我们将其缩短的能力所证明。然而，很难再将代码清单3.3做有意义的缩短。可以将if语句拆出来做一个名为include Setup And Teardonws Ifrestpage的函数，但那只是重新诠释代码，并未改变抽象层级。

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