代码整洁之道--读书总结

函数中传入一个参数有两个常见的形式：一是对这个参数判断，例如 :判断文件是否存在boolean fileExists("fileName")。二是将该参数进行转化，例如：将String类型转换为InputStream类型的返回值 InputStream fileopen("myFile")。因此最好使用可以区分上述两种情景的名称。

还有一种不常见的形式：即返回值为void的函数，实际上是一个事件的处理。这个形式要慎用，而且在命名时尽量让读者了解它是个事件。

要避免编写不遵循以上规则的一元函数，如果要对输入参数进行转换，要体现在返回值上，

StringBuffer transFrom(StringBuffer in) 要比 void transFrom(StringBuffer out) 更符合规范.

2.6.2 标识参数

标识参数丑陋不堪，用布尔值作为入参更是奇葩代码。因为标识参数会让你的函数立刻表现出，它不只做一件事。违反了函数只做一件事的原则。

2.6.3 二元函数

两个参数的函数，要比一个参数的函数难懂。但有的函数天生适合二元函数，例如在确定坐标的函数 piont(x,y)。二元函数会让我们时刻担心入参的顺序。最好是能把二元函数拆解未一元函数。

2.6.4 三元函数

三元函数的会更加复杂难懂，因此在写之前一定要考虑好。

2.6.5 参数对象

三个以上的函数，就可以考虑封装成一个类了，从而减少参数。看着像是在为减少参数作弊，但是当一组参数被共同传递时，往往是该有一个名称概念的时候。

2.6.6 参数列表

要传递数量可变的参数，例如掺入List时，参数就要像上例中那样被对待。同理有可变参数的函数，add(Integer... args )，有可能是一元、二元、或者三元。超过三个犯错的可能性会大大增加。

2.6.7 动词与关键字

给函数取一个好名字，能更好的解释函数的意图以及参数的顺序。函数名称与参数名应该是非常好的，动词/名词对的形式。例如 writeFiled(name).

2.7 无副作用

所谓的副作用就是，违反了函数只做一件事的原则，而它要做的另一件事，却被隐藏在这个函数里。形成一种时序耦合或者顺序依赖，进而导致超出开发者调用该函数的原本用意。

观察如下代码：函数目的是匹配正确的用户名以及密码，成功返回true，失败返回false;

但它有一个副作用，就是会调用Session.initialize()方法，会重新初始化。如果开发者的目的只是校验一下用户名和密码是否正确，那调用该方法就会造成抹除当前会话的风险。

这个副作用实际是一种时序耦合，如果一定要用时序耦合，可以修改函数名，增加函数功能的辨识度，提示到开发人员此函数的用法。本例名称可以修改为：checkPasswordAndInitializeSession。

输出参数

函数中的参数我们一般是作为输入来用的，但是也会出现作为输出的用法，下面这个函数会让人困惑是把s代表的字符串添加到别的字符串后，还是把别的字符串添加到s代表的字符串后。这就需要花时间去调查。

appendStr(s);
//实际函数是，在report后追加
public void appendStr(StringBuffer report);

普遍来说，要避免使用输出参数，如果要必须使用，那就修改所属对象的状态。也就是下面这种写法。

report.appendStr();

2.8 分割指令与询问

不要混淆函数的作用，函数要么回答什么问题，要么做什么事。二者不可得兼。两者放在一起会让读者感到困惑，同时也会产生维护问题。最好的方法就是两个功能分开。

2.9 使用异常代替返回码

2.9.1 抽离try/catch代码块

try/catch代码块搞乱了代码结构，把错误处理与正常流程混在一起。正确大方法是，将代码快内容单独抽离成函数。这样的代码更容易理解和修改。

2.9.2 错误处理就是一件事

函数只处理一件事，错误处理就是一件事。因此在catch/finally代码块后，不应该有其他代码。

2.9.3 Error.java 依赖磁铁

返回错误码，通常暗示有某个类或者枚举定义了错误码

public enum Error{
    OK,
    NO_SUCH,
    LOCKED,
    .....
}

这样的类就是一块依赖磁铁，许多类就要导入和使用它。当Error枚举修改时，所有引用它的类都需要重新编译部署。这就是Error依赖磁铁的负面影响，导致开发人员不愿意添加新的错误类型，而去复用旧的错误编码。

使用异常代替错误码，新异常就能从异常类派生出来，无需编译和重新部署。

2.10 别重复自己

重复可能是软件中一切邪恶的根源，很多原则与实践规则都是为了消除重复。加入你有一段逻辑被重复使用四次，那么当这个逻辑修改的话，就要涉及4处修改。这无疑会让遗漏修改的可能性增加3倍。正确的方式，应该将重复的逻辑抽离成一个公用的方法。

2.11 结构化编程

结构化编程规则：每个函数，函数中的每个代码块，都应该只有一个入口，一个出口。

这就意味着每个函数只有一个return语句，循环中不能出现break、continue关键字，更不能出现goto关键字。但是，这个规则对小函数几乎没有助益作用。只有在大函数中才会有明显的效果。

2.12 如何写出这样的函数

有开发经验的伙伴都有一个体会，就是很难一次性把一个函数写的十分优秀。正确的方法是，先实现需求功能，并且编写测试案例，覆盖每一行代码，然后再保持功能不变的情况下，进行重构和优化。

2.13 本章小结

优秀程序员是把程序当故事来讲，而不是单纯的拼装逻辑。本节的主要讲的是编写良好函数的机制。遵守这些规则，会让你的函数精简有机的结合在一起，帮你讲故事。

三、注释

注释是一把双刃剑，一方面可以进一步阐释作者意图，另一方面会误导读者。总体上注释的反作用出现的机会更大。

代码中的注释，存在的实践越久远，他表达的含义与当前的逻辑含义可能差距越大，进而误导开发人员。过多的注释会让程序显得杂论无章。

开发过程中，要及时更新注释以及删除无效注释。

四、格式

idea工具已具备良好的格式化方式，直接用就好了。

五、对现象和数据格式

5.1 数据抽象

// 案例1
public class point {
    public double x;
    public double y;
}

//案例2
public interface point{
    double getX();
    double getY();
    void setCartesian(double x, double y);
    double getR();
    double getTheta();
    void setPolar(double  r, double  theta);
}

对于处理图形的上述案例中，案例2无疑是更优秀的代码实现。因为案例1暴露了实现，及时它将属性私有化，我们仍然可以通过它提供的取值器与赋值器使用它的变量。案例2的呈现的不只是一种数据结构，还提供了一套存取策略，它隐藏了实现。

隐藏实现表面动作是在变量上加一层函数，而本质思想是对数据进行抽象，以便于对外提供抽象接口，使用户无需了解数据的实现，就能操作数据本体。

数据抽象不只是使用接口、取值器、赋值器，要经过严肃思考，以最佳的方式呈现某个对象包含的数据。

5.2 数据、对象的反对称性

再次回顾5.1中的代码案例，案例1 直接暴露数据，没有提供有意义的函数；案例2将数据隐藏到抽象方法中，提供操作数据的函数。实际上这两种定义的本质是对立的。产生的影响也是深远的。

案例1

大家可以看出案例1为过程式代码，但并不能因此嘲笑这个写法。因为如果给Geometry类添加一个primeter()方法，那些形状类根本不受影响。另一方面，假如新增加一个图形类，那Geometry类就需要修改。注意这两种情况是对立的。

案例2：

案例2的写法是常见的面向对象的写法，当添加一个新的图形类时，已存在的类不需要修改任何代码。但是，加入新增一个color()函数时，就需要修改所有的类。这也是对立的！！！

这体现了对象与数据结构的二分原理。

过程式代码便于在不改动既有数据结构的情况下添加新的函数。面向对象便于在不改动既有函数的情况下添加新的类。

因此，面向对象比较难的事，面向过程就比较容易。反之亦然。因此开发过程中要充分考虑适用的业务场景。

5.3 迪米特法则

1）一个对象应该对其它对象保持最少了解

2）类与类的关系越密切，耦合度越大

3）迪米特法则又叫最少知道原则，即一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部。对外除了提供的public方法，不对外泄露任何信息

4）迪米特法则还有一个更简单的定义：只与直接朋友通信

5）直接朋友：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。耦合的方式有很多，依赖，关联，组合，聚合等。其中我们称出现成员变量，方法参数，方法返回值中的列为直接朋友，而出现在局部变量中的类不是直接朋友。也就是说，陌生的类最好不要以局部变量的形式出现在类的内部

5.3.1 火车失事

String final outPutDior = ctxt.getOptions().getScratchDir().getAbsolutPath();

上述写法被称为火车失事，因为看起来像一列火车，这是一种肮脏的写法，应该避免。

正确的写法是，分开写。

5.3.2 结构混乱。

书中提到上述代码的一个案例，即获取文件路径。但是上述写法需要开发人员取了解目标类的内部细节，类的这些方法也暴露了内部细节，这有违背迪米特法则。在读到后面的代码，发现获取绝对路径的目的是创建一个指定名称的文件夹。所以直接让ctxt对来做这件事，显然更好。

总结

提示：这里对文章进行总结：
例如：以上就是今天要讲的内容，本文仅仅简单介绍了pandas的使用，而pandas提供了大量能使我们快速便捷地处理数据的函数和方法。

愚夫不钓鱼

关注

0
点赞
踩
2

收藏

觉得还不错? 一键收藏
0
评论
代码整洁之道--读书总结

引言：艺术书并不保证你读完之后会成为艺术家，只能告诉你其他艺术家用过的工具，技术和思维过程。本书同理。
复制链接

扫一扫

代码整洁之道--读书总结

系列文章目录

文章目录

前言

一、有意义的命名

1.1 名副其实

1.2 避免误导

1.3 做有意义的区分

1.4 使用读的出来的名称

1.5 使用可搜索的名称

1.6 避免使用编码

1.7 避免映射思维

1.8 类名

1.9 方法名

1.10 别办可爱

1.11 每个概念对应一个词

1.12 别用双关语

1.13 使用解决方案领域名称

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

1.15 添加有意义的语境

1.16 不要添加没用语境的

1.17最后的话

二、函数

2.1 短小

2.2 只做一件事

2.3 每个函数一个抽象层级

2.4 switch语句