《代码整洁之道》 阅读笔记

《代码整洁之道》 阅读之后有种醍醐灌頂的感觉。以前仅仅想着如何快速实现，现在想着如何设计，如何写好代码。

仅记录本人认为重的笔记，而非所有章节的总结，另外，个人也认为书本的最大价值在于1到10章，11章以后的内容，本身涉及的知识就很复杂，作者也不打算细讲（当然，如果细讲，就是另一本书了），是一个总结或着大概。强烈推存多看几次前10章内容。

 

1、整洁的代码

1.1  我们永远无法抛弃代码必要的精确性，所以代码永存！

1.2  我们曾都说过有朝一日回头整理糟糕的代码，然而从来都没有回头过，每天都在这些糟糕的代码中继续前行。勒布朗法则：稍后等于永不

1.3 什么是整洁的代码：优雅、高效、干净利落、明了、尽量少依赖、没有重复代码、易读等等。

 

2、有意思的名称

2.2  名副其实：以下的代码存在4个问题。

修改：

2.3  不要起误导的名称，如userList,但却不是List类型。

2.4  要做有意义的区分，例如不要同时出现ProductData和ProductInfo，会分不清楚两者的区别。

2.5  使用能读得出来的单词，例如：generation,而非gen，不过在国内似乎喜欢缩写，个人建议写全。

2.6  使用可搜索的单词。简单来说：变量名的长的比短的要好。

2.9  来看看，或许是真的

2.10  好像没有毛病

2.14  放心的使用专业术语，如：JobQueue

2.17  变量不要出现与当前语境无关的单词。

3 函数

3.1  短小，无法确定具体的函数，但应该不要超过100行，最佳20行左右，反正总得来说，3000行代码的方法一定会让你头疼。

3.2 函数只做一件事，并把这件事做好。如果一个函数做了很多事情，就得把这件事进行拆分，然后一个函数调用这些被拆分的方法，也就是所谓的上层抽象。

3.3 每个函数一个抽象层级，函数中的方法调用，应该都是同一层级的（同一抽象层）。两个例子：如mvc; 如dao层、service层、controler层。

3.4 switch语句。switch 天生就是要做很多的事情，而又无法不使用switch。我们能做的事情是每个case中的语句最短。在文中也给了一个建议，就是把switch埋在最底层，并能过工厂模式获取出来（当然这个是有使用的条件的）。

3.5 使用描术性的名称。一般来说，名字会比较长，只要合理就行。

3.6 函数参数。参数越少越好，0个最佳，特别是超个3个以上的参数（即4个起）。我认为3个是参数是人可以快速记忆并理解的极限，当参数有4个以上，我们需要额外的时间去理解参数。无特殊的理由，都不应该使用4个以上的参数。（文章中没有提到的方法，仅个人理解：当一个函数中要传入多个参数时，可以尝试把该函数拆分为多个方法）

3.6.1 一个参数的： java的对象参数是引用传递的。当要在函数中改变对象的值，应该返回该对象，而不是默默地改变对象的值。

3.6.2 标识参数（不用最好）：函数中有Boolean 作为参数时，即大声告诉大家，这个函数不止做一件时，在true的时候做一件事，在false做另一件事。这个情况应少用或着不用。经验告诉我，有很多的情况会引起重复代码。

3.6.3 二个参数的：writeFile(String name) 比wirteFile(String name,Stream outputStream)比好。但第二个方法也不算很恶劣，但可能需要点时间去处理理解并处理Stream。当然也有天生就是需要2个参数或多个参数的。如二维标坐标Point(0,0)。如果看到二给坐标是Point(0)这个样。我们一定会很震惊Σ( ° △ °|||)︴。不过，如果能转化为一个参数会更好。

 3.6.4 三个参数的：虽然也不是很险恶，但能够转成二维参数，甚至一维参数会更好。

3.6.5  对象传递：当函数超过三个参数时，最好把参数封装成对象。

3.7  无副作用，即函数只做一件事。例子，用户密码判断的函数，不能在函数里面判断密码对了之后，顺便把Session对象初始化。

3.8 分隔指令与询问：函数要么做什么事，要么回答什么事，两者不可以同时处理。即再次强调一个函数只做一件事。

3.9  函数应该使用异常代替返回错误码。

3.9.1 抽离try / catch 代码块，因为try/cathc实现太难看了。应该使用throws抛出异常，在上层函数捕获。书上的例子是把原来的代码逻辑全部重构成一个方法。

3.9.2 错误处理，就是一件事。即应该就是一个函数来处理。catch/finally 也不应该有其它的方法。（ps:经验告诉我有时候难以避免，例如打开了一个流，就得有一个关闭流的处理。）

3.9.3 简单解释了为什么不能用错误码。反正能不用就不用。

3.10 别重复自己，即尽可能地消灭重复代码

3.11 结构化编程。。。额。。。有兴趣自己看原文，反正不用goto语句就对了。

3.12 如何写出上述规则的函数：看原文。

4 别给糟糕的代码加注释---重写吧/能用代码来表达意思就用代码来表达，如果不能，则要简要说明。好的注释有：1、对意图的解释。2、简单的说明结果。3、警示。4、TODO。

4.N 不要留着注释掉的代码; 不要留作者信息（代码会被其它人改的）; 代码修改后，注释记得也跟着维护，虽然可能不要修改，但如果代码意思已经变了，会引起后来修改的人误会代码的意思的;  不要长篇大论，要简明。

5、格式：大致的意思是，该换行就换行，该缩进就缩进，该对齐的就对齐（注意:等号右边，不要为对齐而对齐），该空格就空格，避免使用protected，实体变量放顶部，看起来整洁顺眼就行。有兴趣的可以自己阅读原文，这部分我建议同时要看《阿里巴巴Java开发手册》。注：《阿里巴巴Java开发手册》跟《代码整洁之道》内容并不是完全一样，差不多是相互补充的。

6 对象与数据结构。问题：变量是用private还是有public? 

6.1数据抽象：变量用privatet，可以制定存取策略，制定一系列原子操作，并把方法抽象为接口,一般来说，都不应该对数据进行直接的操作。最重要一的点就是，让使用者无需知道内部数据结构，就能进行内部数据的操作。一句话，不暴露细节，只暴露抽象接口，让一个复杂的类，使用起来变得简单。

6.2 得墨忒耳律----模块不应该了解它所操作对象的内部情形。文中认为以下的那一行代码是火车失事，是肮脏的。

改为以下代码会好一些：

6.3.3 隐藏结构：上面的代码应该再次封装，放到ctxt里面，直接通过ctxt对象获取到绝对路径。

6.4 数据传送对象：Bean。javaBean比较有意思，就是让某些OO化者论者感觉“舒服”些。就没有别的好处了。(有些框架就是用javaBean来存取数据的，用处还是有的)

7 错误处理

7.1 使用异常，而非返回码。

7.2 先写try-cathc-finally。（stram.close()在意会的代码报异常后怎么执行？个人认为这里不合理）

7.3 使用不可控异常。（不明白这节内容讲了什么，感觉不明觉厉）

7.4 应建立统分的异常信息，和产生的异常传递出去。

7.5 每个异常处理（catch）中都可以包含一堆重复的处理。应该把异常都封装好，调用一个共同的api。

7.6 定义常规流程：1、把异常处理抛得远远的。

7.7 别返回null。如果返回null。就是给自己增加工作量。调用方法时，难道都要判断每个对象是否为null？

7.8 同样，别传递null。

8.边界。

8.1 使用第三方代码时，应该对第三方代码进行封装（隔里），当需要改换第三方代码时，可以快速替换。

8.5 使用尚不存在的代码。即第三方还没有给出接口，也没有相关的实现方法，甚至没有文档。做系统时，如果就先做远离第三方的部分开始做，实现无法避免，则给自己做一个中间件，隔离第三方代码。

9 单元测试-->这部分是测试代码的

9.1  TDD三定律 

    a、先写单元测试代码，再写生产代码

    b、当发现测试代码没有通过，就修改生产代码

   c、修改完上一个生产代码，继续修改写测试代码

9.2 安生产代码的要求一样写测试代码

9.3 整洁的测试代码，分为构造、操作、检验

10 类

10.1 类的组织，尽可能的封装，放松放封装总是下策

10.2 类应该短小。函数是通过代码量来衡量大小。而类则是另一种计算方式，计算权责。

10.2.1 单一权责原则。类或模块应有且只有一条加以修改的理由。再次强调：系统应该由许多短少的类而不是少量巨量类组成的，每个小类封装一个权责，只有一个修改的原因，并与少数的其它类一起协同达成期望值的系统行为。

10.2.2 内聚。当类中的每一个变量都被每一个方法所使用，这种就是完全内聚或着称最大内聚性。一般来说，是不可能创建这样的类的，但尽可能的实现高内聚。高内聚意味着类中的方法和变量相互依赖着，相互结合成一个逻辑整体。当类中不断增加方法和实体变量，方法与实体变量的依赖越来越低时，这意味着可能需要拆出多一个类出来。

10.2.3 保持内聚性就会得来许多短少的类。当大类拆分成小类时，存在许多共用的变量时怎么处理？建义方式依次递减（即最建义第一条）：1、把实体变量也独立出来，成为一个公共的类。2、第个类中都重新定义自己的实体变量。3、把实体变量传递过去。

10.3 为了修改而组织。文中通过一个把当前公用的代码抽取成父类，把能拓展功能全部用子类实现。类对其它类的依赖，应该只依赖其接口，而不必要依赖细节的实现方式。

11 系统

11.2 将系统的构造和使用分开。使用工厂模式，控制反转的依赖注入。

11.4 java 代理。文中没说什么重要的内容，建义自己百度或着谷歌。

11.5 简单介绍发spring aop （建义自己百度）。

11.6 极其简单介绍了AspectJ。（建义自己百度）

12.迭进。整个章节内容不多，可以一句话总结：“去实践吧！”

13 并发编程。整个章节内容不是很多，都在简单介绍并发编程，如果想了解深入，还是要看专门讲并发编程的书籍。