“相对于任何宏伟景愿，对细节的关注甚至是更为关键的专业性基础。首先，开发者通过小型实践获得可用于大型实践的技能和信用度。其次，宏伟建筑中最细小的部分，比如关不紧的门，有点儿没有铺平的地板，甚至是凌乱的桌面，都会将整个大局的魅力毁灭殆尽。这就是整洁代码之所系”----没有比书中的这段话更能说明这本书的意义了。

《代码整洁之道》是第1期书山有路活动选出的读本。相对于记住那些如何写出整洁代码的那些法则，养成保持代码整洁、提高代码质量的习惯和思维更为重要。全书大致分为三个部分，第一部分1-10章都是介绍如函数、类、命名、单元测试等保持整洁的建议。第二部分11-13章从系统设计的层面提倡用AOP、IOC等方式保持整洁，或者合适的时候使用并发编程。第三部分14-17章以及后面的附录，作者以JAVA源码（全书都是以JAVA代码示例）来实际讲解如何保持整洁。

later equals never

我们都曾经瞟一眼自己亲手造成的混乱，决定弃之不顾，走向新的一天。我们都曾经看到自己的烂程序居然能运行，然后断言能运行的烂程序总比什么都没有强，我们都曾经说过有朝一日再回头清理。当然，在那些日子里。我们都没有听过布朗法则：later equals never 稍后等于永不.

ps:看到这句话确实有点惭愧。印象最深的感觉就是，我们去看一两年前自己的代码。那是写的什么玩意，真的是自己都看不下去。要让我改，我情愿再实现一个。所以时刻保持好的习惯是多么重要。不要想着以后再解决。就像领导说，这个事情以后再考虑，然后就没有然后了。

第一章 整洁代码

怎样是整洁的代码？

Bjarne Stroustrup（C++发明者） 说：

“我喜欢优雅和高效的代码，代码逻辑应当直接了当，叫缺陷难以隐藏；尽量减少依赖关系，使之便于维护；依据某种分层战略完善错误处理代码；性能调至最优，省得引诱别人做没有必要的优化，搞出一堆混乱来，整洁的代码之做好一件事。”

Ron Jeffries 对整洁代码的理解：

1.能通过所有的测试。

2.没有重复代码。

3.体现系统中的全部设计理念。

4.包含尽量少的实体、比如类、方法、函数等。

“在以上诸项中，我最在意的是代码重复。如果一段代码重复出现，就表示某种想法未在代码中得到良好的提现。我会尽力去找出到底那是什偶么，然后在尽力的更清晰的表达出来。”

PS：总结下就是整洁的代码1.职责明确，没有多余，2.减少依赖，便于维护。3.高效。

第二章  有意义的命名

1.名副其实。 说起来很简单。选个好名字需要花时间，但省下的时间比花掉的多。注意命名，一旦有好的命名，就换掉旧的。

intd;//消失的时间，以日计。intelapsedTimeInDays;

PS:Ctrl+R+R蛮好用的。实际中的情况要比我贴出来的复杂。我们定义不同的变量，能够看到名字就知道是什么意思，这是最基本的要求了。

2.避免误导。比如不是List类型，就不要用个accountList来命名，这样形成误导。

3.做有意的区分。

Public static void copyChars(chara1[],chara2[]){for(inti=0;i

a2[i]=a1[i];

} }

如果参数名称改为source和destination ，这个函数就会像样很多。废话都是冗余的，Variable一词 永远不应当出现在变量名中。Table一词永远不应当出现在表名中。NameString 会比 Name好吗，难道Name 会是一个浮点数不成？如有一个Customer的类，有又一个CustomerObject的类。是不是就凌乱了。

4.使用便于搜索的的名称

单个字母或者数字常量是很难在一大堆文章中找出来。比如字母e，它是英文中最常用的字母。长名胜于短名称，搜得到的名称胜于自编的名称。 窃以为单字母的名称仅用于短方法中的本地变量。名称长短应与其作用域大小相对应。

5.类名应该是名词或短语，像Customer，Account，避免使用Manager,Processor,Data或者Info这样的类名。类名不应当是动词。方法名应该是动词或动词短语，如postPayment ,deletePage或Save，属性访问、修改和断言应该根据其值来命名，并加上get，set，is这些前缀。

6.别扮可爱，耍宝，比如谁知道HolyHandGrenada 函数是干什么的，没错这个名字挺伶俐，但是不过DeleteItems或许是更好的名字。

7.每个概念对应一个词。并且一以贯之。

在一堆代码中有Controller，又有manager，driver。就会令人困惑。比如DeviceManager和Protal-Controller之间又什么本质区别？

第三章 函数

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

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

3.尽量少的函数参数。有两个参数的函数要比一元函数的难懂。如果需要三个或者三个以上的参数应该封装成类了。

4.不要重复自己。

PS:如果一段相同的代码出现了两次，你是不是觉得自己改做些什么了。

第四章 注释

注释的恰当用法是弥补我们在用代码表达意图时遭遇的失败。作者认为注释是一种失败，我们总无法找到不用注释就能表达自我的方法，所以总要有注释，这并不值得庆贺。写注释的常见动机之一是糟糕代码的存在。带有少量注释的整洁而有表达力的代码，要比带有大量注释的零碎而复杂的代码像样的多。与其花时间编写解释你搞出的糟糕的代码注释，不如花时间清洁那堆糟糕的代码。

PS:这段话看起来可能有些过激。我们确实可以通过好的编码习惯减少不必要的注释。不过现在自动生成文档的技术都是从代码的注释中提取的。如果是这种情况，上司肯定是要求你写完备的注释的。

好注释：

1. 法律信息。有时，公司代码规范要求编写与法律有关的注释。例如版权和著作申明。

2.提供信息的注释。

//returen an instance of the Responder being testedprotectedabstractResponder responderInstance();

不过作者认为 将函数名 重新命名为 responderBeingTested 注释就是多余的。

3.对意图的解释。 有时注释不仅提供了有关实现的有用信息，而且还提供了某个决定后面的意图。

4.阐释。 有时注释把某种晦涩难明的参数或返回值的意义翻译为某种可读形式。也会是有用的。特别是参数或者返回值是某个标准库的一部分，或者你不能修改代码，那帮助阐释其含义的代码就会有用，例如:

assertTrue(bb.compareTo(ba)==1);//bb>aaassertTrue(a.compareTo(b)==-1);//a

直接看方法可能不明确，但有注释就明白多了。我看这2,3,4都是一个意思。就是说明是干嘛的。

5.警示，告诉别人要注意这个方法之类的。

6.放大。有的代码可能看着有点多余，但编码者当时是有他自己的考虑，这个时候需要注释下这个代码的重要性。避免后面被优化掉。

第五章 格式

纵向格式：

1. 函数与函数之间留空行。

2.变量声明：变量声明应该尽可能靠近其使用位置。因为函数很短，本地变量应该在函数的顶部出现。

3.实体变量 应该在内的顶部，相当于我们的field 字段，会被使用的多。

4.相关函数，如果某个函数调用另外一个，就应该把他们放在一起，而且调用者应该尽可能放在被调用者的上面。这样这个程序就会自然有序。（之前我喜欢把private的方法 放到一起。当然这确实没有什么实际的意义）

5.“相关概念的代码放在一起。相关性越强，比如一个大功能逻辑靠在一起。” （更多的时候我喜欢用 region 来收起来。）

横向格式：

1.一行的长度，作者建议是上限是120个字符

PS 平时我们都是按照自己的屏幕大小来决定，当然太长了，自己也不便阅读，又不是压缩的js文件

2.赋值语句两端留空。

a = b ;

3.不在函数名和左括号间加空格。因为函数与其参数密切相关。

4.缩进。源文件是一种继承结构，而不是一种大纲结构，继承结构中的每一层级都圈出一个范围， 也就是代码块，其中有声明语句和执行语句。要体现这种继承结构，就要对源代码进行缩进处理。但有时候我们会把if语句，while循环，或小函数写成一行，但这样没有层级的概念，不便阅读，还是缩进的好。

第六章 对象和数据结构

1.过程式代码（函数编程）便于在不改动既有数据结构的前提下添加新函数，面向对象代码便于在不改动既有函数的前提下添加新类。反过来讲也说的通,过程式代码难以添加新的数据结构，因为必须修改所有函数，面向对象代码难以添加新函数，因为必须修改所有类。所以在设计的时候要分析好是以后是要添加新函数还是要添加新的数据结构。

2.德墨忒尔律：模块不应该了解它所操作对象内部情形。比如C的方法f只能调用以下对象的方法。

C

由f创建的对象

作为参数传递给f的对象

C的实体变量持有的变量

varoutpath=cxt.getOptions().getScart().getAbsolutePath();

这个代码就违反了上面的德墨忒尔律，调用了返回值的方法。这样就是暴露了内部结构。

第七章 异常处理

1.try代码就像是事务，catch代码块将程序维持在一种持续状态。在编写可能抛出异常的代码时，最好先写出try-catch-finally 语句。

2.根据需要定义异常类。对错误分类的方式有多种，可以依据来源，是组件还是其他地方，或者依据类型，是设备错误还是网络错误。不过在我们定义异常类的时候，最重要的考虑是如何捕获它们。

3.别返回null值。程序中不断的看到检测null值的代码，一处漏掉检测就可能会失控。返回Null，作者认为这种代码很糟糕。建议抛出异常 或者返回特定对象（默认值）。更早的发现问题。同理，也应该避免传递Null值给其他的方法。

PS:在大多数的编程语言中，没有良好的方法能对付由调用者意外传入的null值。我们发布产品应该有容错的机制，程序不能轻易的就崩掉，有异常应该及时记录下来或给出提示。

第八章 边界

有时候我们在使用第三方程序包或者开源代码的时候，或者依靠公司其他团队的代码，我们都得干净利落的的整合进自己的代码中。这一章就是介绍保持保持软件边界整洁的实践手段和技巧。

1.对第三方进行学习性测试，当第三方程序包发布了新的版本，我们可以允许学习性测试，看看程序包的行为有没有发生改变。

2.使用尚不存在的代码，有时候我们的第三方，还没有开发好API，但又不能影响到我们的开发进度，所以我们先可以定义好自己想要的接口。如果第三方ok了，我们再对接起来。

3.通过接口管理第三方边界，可以使用ADApter模式将我的接口转换为第三方提供的接口。这个是要注意，第三方的代码和自己的代码混合太多，这样不便管理。

第九章  单元测试

敏捷和TDD运动鼓舞了许多程序员编写自动化单元测试，单元测试是确保代码中的每个犄角旮旯都如我们所愿的工作。

TDD三定律

除非这能让失败的单元测试通过，否则不允许去编写任何的生产代码。

只允许编写刚好能够导致失败的单元测试。 （编译失败也属于一种失败）

只允许编写刚好能够导致一个失败的单元测试通过的产品代码。

PS:什么是生产代码，这里有点迷惑。

测试代码和生产代码一样重要，它可不是二等公民，它需要被思考、被设计和北照料。它该像生产代码一样保持整洁。单元测试让你的代码可扩展，可维护，可复用。原因很简单，有了测试，你就不担心对代码的修改，没有单元测试，每次修改可能带来缺陷，一个测试，一个断言。一个测试，对应一个概念。我们不想要超长的测试函数。

测试还应遵守以下5条规则。

1.快速 测试应该能快速运行，太慢了你就不会频繁的运行，就不会尽早的发现问题。

2.独立。测试应该相互独立，某个测试不应该为下个测试设定条件。当测试相互依赖，一个没通过导致一连串的测试失败，使问题诊断变的困难。

3.可重复。测试应该可以在任何环境中重复通过。

4.自足验证 测试应该有布尔值输出，无论通过或失败，不应该是查看日志文件去确认

5.及时。单元测试应该恰好在使其通过的生产代码之前编写。

PS 不知道实际开发中，各个公司是怎么要求的。团队开发会有要求单元测试，个人开发我几乎是没有写单元测试了。

第十章  类

1.类应该短小

2.单一权责原则(SRP)：类或模块应有且只有一条加以修改的理由。系统应该有许多短小的类而不是巨大的类组成。

PS：每个达到一定规模的系统都会包括大量逻辑和复杂性。管理这种复杂性的首要目标就是加以组织，以便开发者在哪儿能找到东西，反之，拥有巨大、多目的的类的系统，总是让我们在目前并不需要了解的一大堆东西中艰难的跋涉。

3.内聚：如果一个类中的每个变量都被每个方法所使用，则该类具有最大的内聚性。内聚性高，意味着类中的方法和变量相互依赖，相互结合成一个逻辑整体。

4.为了修改而组织。开放闭合原则（OCP）：类应当对扩展开放，对修改封闭。我们可以借助接口和抽象类来隔离这些细节带来的影响。

第十一章：系统

将系统的构造和使用分开：构造和使用是不一样的过程。

PS：修建一栋大楼的时候，起重机和升降机在外面，工人们穿着安全服在忙碌。当大楼建设完成，建筑物变得整洁，覆盖着玻璃幕墙和漂亮的漆色。在其中工作的人，看完完全不同的景象。软件也是如此，将关注的方面分离。

1.工厂，有时候应用程序需要确定何时创建对象，我们可以使用抽象工厂模式。将构造的细节隔离于应用程序之外。

2.依赖注入（DI/IOC）。在依赖管理情景中，对象不应该负责实例化对自身的依赖，反之，它应该将这份权责移交给其他有权利的机制，从而实现控制的反转。

PS 现在的依赖注入组件比较多了，Autofac，Ninject等。

3.扩容：“一开始就做对的系统”纯属神话，反之，我们应该只实现今天的用户的需求。然后重构，明天再扩容系统，实现新用户的需求。这就是迭代和增量敏捷的精髓所在。 就像城市不断的再拆掉，再建设。

4.面向切面编程。AOP中，被称为方面（aspect）的模块构造指明了系统中哪些点的行为会以某种一致的方式被修改，从而支持某种特定的场景。这种说明是用某种简洁的声明(Attribute)或编程机制来实现的。

PS:MVC的Filter是个很好的AOP，可以从权限验证，方法进入前，方法进入后，返回结果前，返回结果后等这几个横切面进行编程。更好的组织代码。第十，十一章讲的设计只是一少部分。更多的可能要去参考专门讲设计模式之类的书。

第十二章 迭进

1.简单设计规则 1：运行所有测试。

紧耦合的代码难以编写测试。同样编写测试越多，就会越遵循DIP之类的原则，使用依赖注入，接口和抽象等工具尽可能减少耦合。如此一来设计就会有长足进步。遵循有关编写测试并持续运行测试的、明确的规则，系统就会更贴近OO低耦合度、高内聚的目标。

2.简单设计规则2 重构：

在重构过程中，可以应用有关优秀软件设计的一切知识，提升内聚性，降低耦合度。换句话说：消除重复，保证表达力，尽可能的减少类和方法的数量。

3.不可重复。重复是良好设计系统的大敌。它代表着额外的工作、额外的风险和额外不必要的复杂度。重复有多种表现。雷同的代码行是一种。另外的比如：

intsize();boolisEmpty();

这两个方法可以分别实现，但可以在isEmpty中使用size消除重复。

boolisEmpty(){returnsize()==0;

}

不但是从代码行的角度，也要从功能上消除重复。

第十三章： 并发编程

并发是一种解耦策略，它帮助我们把做什么(目的)和何时（时机）做分解开。在单线程应用中，目的与时机紧密耦合，很多时候只要查看堆栈追踪即可断定应用程序的状态。而解耦目的与时机能明显地改进应用程序的吞吐量和结构。从结构的角度看，应用程序看起来更像是许多台协同工作的计算机,而不是一个大循环。单线程程序许多时间花在等待Web套接字I/O结束上面。

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

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

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

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

一些基础定义：

在并发编程中用到的几种执行模型。

1）生产者-消费者模型

一个或多个生产者线程创建某些工作，并置于缓存或者队列中。一个或者多个消费者线程从队列中获取并完成这些工作。生产者和消费者之间的队列是一种限定资源。

2）读者-作者模型。

当存在一个主要为读者线程提供信息源，但只是偶尔被作者线程更新的共享资源，吞吐量就会是个问题。增加吞吐量，会导致线程饥饿和过时信息的积累。协调读者线程不去读取正在更新的信息，而作者线程倾向于长期锁定读者线程。

3）宴席哲学家。

许多企业级应用中会存在进程竞争资源的情形，如果没有用心设计，这种竞争会遭遇死锁，活锁，吞吐量和效率低等问题。

PS：这里对并发的讲解还不是那么的清晰，要掌握怎么正确使用并发，自己还是需要去专门看看这方面的书。

小结：书十三章之后的部分是一些java源码的优化过程的讲解，我不太懂java，这里先略过。本书最有价值的地方在于让我们程序员要有些整洁代码的习惯。从细微的变量命令，到函数、类的设计、以及整个系统的构造。不能忽略每一道工序。坏的代码就像沼泽，会让人越陷越深，很难改动，所以我们从一开始就要写整洁的代码。而至于设计模式或并发编程，从其他的书籍学习更全面。这本书满足不了我们的需求。

PS：书山有路活动是读书群的朋友共同选出来一起读的一本书。《代码整洁之道》是第一期。我是读书人，这本书一共读了七天。每天大概一个多小时。但是今天整理笔记，基本上全书又过了一遍。笔记内容也是依据我自己的判断。如果你想获得全面的了解，还是要请看原书。我们第二期正在读的书籍是《失控》，欢迎有兴趣的朋友加入 qq群452450927。