《代码整洁之道》--函数

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

函数不应该大到足以容纳嵌套结构。函数的缩进层级不应该多于一层或两层。

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

如果函数只是做了该函数名下同一抽象层上的步骤，则函数还是只做了一件事。

判断函数是否不止做了一件事，有一个方法，就是看能否再拆出一个函数，该函数不仅只是单纯地重新诠释其实现。

只做一件事的函数无法被合理地切分为多个区段。

每个函数一个抽象层级，函数中混杂不通抽象层级，往往让人迷惑。

自顶向下读代码：向下规则。

可以将switch语句埋到抽象工厂底下，不让任何人看到，并创建多态对象。

函数越短小，功能越集中，就越便于取个好名字。

别害怕长名称。长而具有描述性的名称，要比描述性的长注释好。别害怕花时间取名字。Eclipse该名称易如反掌。

模块命名方式要保持一致。

最理想的参数数量是0，其次是1，再次是2，应该尽量避免3个参数。有足够特殊理由才能用三个以上参数--所以无论如何也不要这么做。

参数与函数名处在不同的抽象层级，它要求你了解目前并不特别重要的细节。

从测试角度看，参数甚至更叫人为难。输出参数比输入参数还要难以理解。

对于转换，使用输出参数而非返回值令人迷惑。如果函数要对输入参数进行转换操作，转换结果就该体现为返回值。

 

标识参数丑陋不堪。向函数传入布尔值简直就是骇人听闻的做法。这样做，方法签名立刻变得复杂起来，大声宣布本函数不止做一件事。

 

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

 

函数专心做好一件事，不要带来副作用。

 

函数要么做什么事，要么回答什么事，但二者不可兼得。解决方案是把指令与询问分割开来，防止混淆的发生。

 

使用异常替代返回错误码。

从指令式函数返回错误码轻微违反了指令与询问分隔的规则。它鼓励了在if语句判断中把指令当作表达式使用。

if（deletePage（page） == E_OK）这样的代码会导致更深层次的嵌套结构。当返回错误码时，就是在要求调用者立刻处理错误。

 

抽离Try/Catch代码块。最好把try和catch代码块的主体部分抽离出来，另外形成函数。

 

错误处理就是一件事，处理错误不该做其他事。如果关键字try在某个函数中存在，它就是这个函数的第一个单词，而且在catch/finally代码块后面也不该有其他内容。

 

 

Error.java依赖磁铁。

 

返回错误码通常暗示某处有个类或者是美剧，定义了所有错误码。

这样的类就是一块依赖磁铁，其他许多类都导入和使用它，当Error枚举修改时，所有这些其他类都需要重新编译和部署。

使用异常替代错误码，新异常就可以从异常类派生出来，无需重新编译或重新部署(这是开放闭合原则OCP的一个范例）。

 

如果使用异常替代返回错误码，错误处理代码就能从主路径代码中分离出来，得到简化。

 

别重复自己。重复可能是软件中一切邪恶的根源。

 

并不一开始就按照规则写函数，没人能做到。学会单元测试，不断打磨代码才是王道。

 

大师级程序员把系统当作故事来讲，而不是当作程序来写。记住，编程是一种艺术。