代码整洁之道 - 阅读笔记 （二）

#代码整洁之道 - 阅读笔记（二）

第三章 函数

很喜欢第三章的插图：庞大、畸形、混乱，表征不好的函数构造。

好的函数应该具备的特征包括：

• 短小
• 只做一件事
• 每个函数一个抽象层级
• switch语句
• 使用描述性名称
• 函数参数（尽量少）
• 无副作用
• 分割指令与询问
• 使用异常返回替代错误码
• 别重复自己
• 结构化编程

先看一段好的函数与不好的函数：

【图片加载不出来，自行看书，见章节：3-0】

这两段代码，很明显就看得出来那段代码是好的。从直观上描述：好的代码就是易懂的。针对于上述几种规则，对个别常见错误进行详细说明。

#3.1 短小

函数的第一规则是要短小。

短小在于：函数包括的行数不能太长，建议不超过20行，每行包括的字符不能太多，建议不超过150个字符。

代码块和缩进

if语句、else语句、while语句等，其中的代码块应该只有一行。该行大抵应该是一个函数调用语句。这样不但能保持函数短小，而且因为块内调用的函数拥有较具说明性的名称，从而增加了文档上的价值。

这也意味着函数不应该达到足以容纳嵌套结构。所以，函数的缩进层级不应该多于一层或两层。这样的函数才更加易于阅读和理解。

#3.2 只做一件事

根据缩写的代码，完成具体的单个业务模块，不要嵌套！！！

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

要确保函数只做一件事，函数中的语句都要在同一抽象层级上。混杂不同抽象层级，往往让人迷惑。可能无法判断某个表达式是基础概念还是细节。更恶劣的是，细节与基础概念混杂。

自顶向下读代码，向下规则：想要代码拥有自顶向下的阅读顺序。我们想要让每个函数后面都跟着位于下一抽象层级的函数，这样一来，在查看函数列表时，就能循抽象层级向下阅读了。如：

#3.6 函数参数

最理想的参数数量是0，其次是1，再次是2。参数传递时，具有太多的概念性，每次都要翻译一遍，不易于理解。从测试角度看，参数越多，编写确保参数的各种组合运行正常的测试用例，是很浑南的事情。

##3.6.1 一元函数的普遍形式

向函数传递单个参数的两种普遍理由：（一）问关于那个参数的问题；（二）函数是一个事件，利用该参数修改系统状态。

第一种理由：问关于那个参数的问题，操作该参数，将其转换为其他什么东西，要在一致的上下文使用这两种形式。

第二种理由：程序将函数作为是一个事件，使用该参数修改系统状态，小心使用这种形式，应该让读者很清楚地了解他是个事件，谨慎的选用名称和上下文。

##3.6.2 标识参数

标识参数不应该传入，将true和false作为参数传入函数。

##3.6.3 二元函数

二元函数的业务意义要很清楚。

##3.6.5 参数对象

如果函数看来需要两个、三个或以上的额参数，就说明其中一些参数应该封装为类了。

从参数创建对象，从而减少参数数量，看起来想作弊，但实则并非如此。当一组参数被共同传递，往往就是该有自己名称的某个概念的一部分。

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

从指令式函数返回错误码轻微违反了指令与询问分割的规则，鼓励了再if语句判断中把志玲当做表达式使用。

错误示例为：

正确示例为：

使代码更加简化，且易于理解。

额(⊙o⊙)…，想要写出好的函数，要写，复看，复检，再复检。