代码整洁之道 代码整洁之道 代码整洁之道-1.图书信息，代码整洁之道-2.图书信

代码整洁之道_代码整洁之道 -1.图书信息

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

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

《代码整洁之道》：细节之中自有天地，整洁成就卓越代码

尽管糟糕的代码也能运行，但如果代码不整洁，会使整个开发团队泥足深陷，写得不好的代码每年都要耗费难以计数的时间和资源。然而这种情况并非无法避免。

著名软件专家RoberfC.Marlin在《代码整洁之道》中为你呈现出了革命性的视野。Martin携同ObjectMetltor公司的同事，从他们有关整洁代码的最佳敏捷实践中提炼出软件技艺的价值观，以飨读者，让你成为更优秀的程序员――只要你着手研读《代码整洁之道》。

阅读《代码整洁之道》需要你做些什么呢？你将阅读代码――大量代码。《代码整洁之道》促使你思考代码中何谓正确，何谓错误。更重要的是，《代码整洁之道》将促使你重新评估自己的专业价值观，以及对自己技艺的承诺。

从《代码整洁之道》中可以学到：好代码和糟糕的代码之间的区别：如何编写好代码，如何将糟糕的代码转化为好代码：如何创建好名称、好函数、好对象和好类；如何格式化代码以实现其可读性的最大化：如何在不妨碍代码逻辑的前提下充分实现错误处理；如何进行单元测试和测试驱动开发。

作者：(美国)马丁(Robert C. Martin) 译者：韩磊

Robert C. Martin，是软件工程领域的大师级人物，是《敏捷软件开发：原则、模式与实践》、《敏捷软件开发：原则、模式与实践(C#版)》（邮电）、《极限编程实践》（邮电）等国内引进的畅销书的作者，其中第一本原著荣获美国《软件开发》第13届震憾（Jolt）大奖，Martin的敏捷系列书是软件工程界的权威书籍。本书是他的又一最新力作。

Martin在书中对代码具有革命性的解读

阐述了整洁代码的最佳敏捷实践的方法

书中介绍规则均来自Martin多年的经验，拥有很高的借鉴价值

韩磊，互联网产品与运营专家，技术书籍著译者。曾在全球著名的IT中文社区CSDN及《程序员》杂志任副总经理、总编辑等职。现居广州。译著有《梦断代码》和《C#编程风格》。与刘韧合著《网络媒体教程》，与戴飞合译《BeginningC#Objects中文版：概念到代码》。

第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.4switch语句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.3Error.java依赖磁铁44

3.10别重复自己44

3.11结构化编程45

3.12如何写出这样的函数45

3.13小结45

3.14SetupTeardownIncluder程序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.6TODO注释54

4.3.7放大54

4.3.8公共API中的javadoc55

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.13HTML注释64

4.4.14非本地信息64

4.4.15信息过多65

4.4.16不明显的联系65

4.4.17函数头66

4.4.18非公共代码中的Javadoc66

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学习log4j108

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

8.5使用尚不存在的代码110

8.6整洁的边界111

8.7文献112

第9章单元测试113

9.1TDD三定律114

9.2保持测试整洁115

9.3整洁的测试116

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

9.3.2双重标准119

9.4每个测试一个断言121

9.5F.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分解main143

11.2.2工厂143

11.2.3依赖注入144

11.3扩容145

11.4Java代理148

11.5纯Java AOP框架150

11.6Aspectj的方面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.1Args的实现177

14.2Args：草稿183

14.2.1所以我暂停了195

14.2.2渐进195

14.3字符串参数197

14.4小结234

第15章JUnit内幕235

15.1JUnit框架236

15.2小结249

第16章重构SerialDate251

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.5Java288

17.6名称291

17.7测试294

17.8小结295

17.9文献296

附录A并发编程II297

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.1executor框架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

附录Borg.jfree.date.SerialDate327

结束语389

乐嚼（Ga.J01）是在丹麦最受欢迎的糖果品种之一，它浓郁的甘草味道，完美地弥补了此地潮湿且时常寒冷的天气。对于我们这些丹麦人，乐嚼的妙处还在于包装盒顶上印制的哲言慧语。今早我买了一包两件装，在其包装盒上发现这句丹麦谚语：“小处诚实非小事。”这句话正好是我想在这里说的。以小见大。本书写到了一些价值殊胜的小主题。

神在细节之中，建筑师（路德维希・密斯・范・德・罗）如是说。这句话引发了有关软件开发、特别是敏捷软件开发中架构所处地位的若干争论。鲍勃（Bob）2和我时常发现自己沉湎于此类对话中。没错，LudwigmiesVanderRohe的确专注于效用和基于宏伟架构之上的永恒建筑形式。然而，他也为自己设计的每所房屋挑选每个门把手。为什么？因为小处见大。

就TDD3话题展开目前仍在继续的“辩论”时，鲍勃和我认识到，我们均同意软件架构在开发中占据重要地位，但就其确切意义而言，我们之间还有分歧。然而，这种矛与盾孰利的讨论相对而言并不重要，因为在项目开始之时，我们理所当然应该让专业人士投入些许时间去思考及规划。20世纪90年代末期有关仅以测试和代码驱动设计的概念已一去不返。相对于任何宏伟愿景，对细节的关注甚至是更为关键的专业性基础。首先，开发者通过小型实践获得可用于大型实践的技能和信用度。其次，宏大建筑中最细小的部分，比如关不紧的门、有点儿没铺平的地板，甚至是凌乱的桌面，都会将整个大局的魅力毁灭殆尽。这就是整洁代码之所系。

架构只是软件开发用到的借喻之一，主要用在那种等同于建筑师交付毛坯房一般交付初始软件产品的场合。在Serum和敏捷（Agile）的日子里，人们关注的是快速将产品推向市场。我们要求工厂全速运转、生产软件。这就是人类工厂：懂思考、会感受的编码人，他们由产品备忘或用户故事开始创造产品。来自制造业的借喻在这种场合大行其道。例如，Serum就从装配线式的日本汽车生产方式中获益良多。

代码整洁之道_代码整洁之道 -2.图书信息

软件质量，不但依赖于架构及项目管理，而且与代码质量紧密相关。这一点，无论是敏捷开发流派还是传统开发流派，都不得不承认。《代码整洁之道(英文版)》提出一种观念：代码质量与其整洁度成正比。干净的代码，既在质量上较为可靠，也为后期维护、升级奠定了良好基础。作为编程领域的佼佼者，《代码整洁之道(英文版)》作者给出了一系列行之有效的整洁代码操作实践。这些实践在《代码整洁之道(英文版)》中体现为一条条规则（或称“启示”），并辅以来自现实项目的正、反两面的范例。只要遵循这些规则，就能编写出干净的代码，从而有效提升代码质量。《代码整洁之道(英文版)》阅读对象为一切有志于改善代码质量的程序员及技术经理。书中介绍的规则均来自作者多年的实践经验，涵盖从命名到重构的多个编程方面，虽为一“家”之言，然诚有可资借鉴的价值。

RObert Ma rlin，(Bob大叔)自1970年进入软件行业，从1990年起成为国际软件咨询师。

Chapter 1: Clean Code 1

There Will Be Code2

Bad Code3

The Total Cost of Owning a Mess4

The Grandredesignin the Sky5

Attitude5

The Primalconundrum6

The Art of Clean Code?6

What Is Clean Code?7

Schools of Thought12

We Are Authors13

The Boy Scout Rule14

Prequel and Principles15

Conclusion15

Bibliography15

Chapter 2: Meaningful Names17

Introduction17

Use Intention-Revealing Names18

Avoid Disinformation19

Make Meaningful Distinctions20

UsepronounceableNames21

Use Searchable Names22

Avoid Encodings23

Hungarian Notation23

Member Prexes24

Interfaces and Implementations24

Avoid Mental Mapping25

Class Names25

Method Names25

Don't Be Cute26

Pick One Word per Concept26

Don't Pun26

Use Solution Domain Names27

Use Problem Domain Names27

Add Meaningful Context27

Don't AddgratuitousContext29

Final Words30

……

爱华网本文地址 » http://www.aihuau.com/a/8103320103/57150.html