cleanCode-函数

    函数或者方法（以下统称为函数），是我们日常编程工作中不可或缺的一部分。然而，我们真的把函数写好了吗？
结合我自己工作中接触的代码和书中的建议，总结一些写好函数的要素。
    1.函数应该短小。这条建议更像一个评价标准而不是约束，因为单纯的约束函数的长度往往不会收到很好的效果。但是，如果函数的长度太长，我们则需要提醒自己“代码还没有写完”。如果按照下面的建议依次来规整自己的代码，函数的长度大概率会变得理想。
    2.函数应该专一。整洁的函数应该只负责一件事，并且负责好这件事。多功能的函数虽然一时省事，但是经不起扩展和修改，会随时间慢慢变得臃肿和低效。生命还很顽强，没人敢动，几乎和整个模块共生死。
    3.每个函数是一个抽象层级。在同一个函数中，不要存在不同抽象层次的代码。举个简单的例子，某函数A实现功能需要2步，第一步调用已封装好的接口获取数据，第二步实现对数据的解析。这时对函数A的来讲，第一步和第二步就属于不同的抽象层级。因此需要将第二步抽象成函数B，然后在函数A中调用函数B。这有点像模板模式的写法：上层决定流程，下层决定实现。上下层彼此独立，互不认识。
向下规则：在函数的后面跟着位于下一抽象层级的函数。
    4.函数应该具有合理的抽象，这也是非常普遍的问题。一个上千行的函数，尽管遵守了只实现一个功能和一个抽象层级的约束，但是里面充斥着各种彼此毫不相关的代码段。每段代码实现什么样的功能全靠注释去理解。功能不应该由一个函数来完成，而是一系列层次分明、精细分工的函数。
    5.函数的命名应该具有自描述的能力。而且随着层次的划分，很容易起名字把事情说清楚。如果函数带有参数，那么命名最好和参数的命名有交互。
    6.函数的参数个数应该尽量少，最好是0个。而且不要使用输出参数。
    7.对待try-catch代码块，尽量使用单独的函数来处理。不要把实现功能的代码和处理异常的代码放在一处。这会让代码的结构看起来非常的难看。想想看一段代码，每一两行就会碰到一个try-catch，throw不同的exception。这种情况下至少应该把所有的代码放到一个try-catch块中去，然后统一的catch每种不同的异常进行处理。更好一点的做法是，把try-catch转移至上游函数，本函数只保留实现功能的代码。
    书中提到的“使用异常替代返回错误码”我持保留意见。如果错误码属于正常的业务流程，则不该使用异常。因为我们不该使用异常去代替逻辑分支。否则的话，就可以使用异常。因为这样可以简化处理流程。比如函数内的参数判空逻辑，在参数为空就无法执行时，可以考虑使用异常去代替if-return结构。