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

1、函数的第一规则是要短小。第二规则是还要更短小。
2、每个函数都只有两行、三行、四行长，每个函数都一目了然，每个函数都只说一件事，每个函数都依序把你带到下一个函数
3、if语句、else语句、while语句等，其中的代码块应该只有一行。该行大抵应该是一个函数调用语句。这样不仅仅能保持函数短小，而且，因为块内调用的函数拥有较具说明性的名称，从而增强了文档上的价值。这也意味着函数不应该大到足以容纳嵌套结构。所以，函数的缩进层级不该多于一层或两层。当然，这样的函数易于阅读和理解。
4、函数只做一件事。做好这件事，只做一件事。如果函数只是做了该函数名下同一抽象层上的步骤，则函数还是只做了一件事。编写函数毕竟是为了把大一些的概念拆分为另一抽象层上的一系列步骤。
要判断函数是否不止做了一件事，还有一个方法，就是看是否能再拆出一个函数，该函数不仅仅只是单纯的重新诠释其实现。
只做一件事的函数无法被合理的切分为多个区段。
5、要确保函数只做一件事，函数中的语句都要在同一抽象层级上。
6、对于swhich语句，如果只出现一次，用于创建多态对象，而且隐藏在某个继承关系中，在系统其他部分看不到，就还好。当然了，也要就事论事，有时候也可以部分或全部违反这条规矩。
7、“如果每个例程都让你感到深合己意，那就是整洁代码。”—-沃德原则
8、函数越短小，功能越集中，就越便于取个好名字。
别害怕长名称。长而具有描述性的名称，要比短而令人费解的名称好。长而具有描述性的名称，要比描述性的长注释好。使用某种命名约定，让函数名称中的多个单词容易阅读，然后使用这些单词给函数取个能说清其功用的名称。
选择描述性的名称能理清你关于模块的设计思路，并帮你改进之。追索好名称，往往导致对代码的改善重构。
命名方式要保持一致。使用与模块名一脉相承的短语、名称和动词给函数名称。
8、最理想的参数数量是零，其次是一，再次是二，应尽量避免三个数量的参数函数。
9、如果参数多于两个，测试覆盖所有可能值的组合简直让人生畏。
10、输出参数比输入参数还要难以理解。读函数时，我们惯于认为信息通过参数输入函数，通过返回值从函数输出。我们不太期望信息通过参数输出。所以，输出参数往往让人苦思之后才恍然大悟。相较于没有参数，只有一个输入参数算是第二好的做法。
11、向函数传入单个参数有两种极普遍的理由。可能是操作该参数，将其转换为其他什么东西，再输出之；还有一种虽不那么普遍但仍极有用的单参数函数形式，那就是事件，在这种形式中，有输入参数而无输出参数。
12、标识参数丑陋不堪。向函数传入布尔值简直就是骇人听闻的做法。这样做，方法签名立刻变得复杂起来，就如同宣布本函数不止做一件事。
13、有两个参数的函数要比一元函数难懂。当然，有时候两个参数正好。
14、有三个参数的函数要比二元函数难懂得多。排序、琢磨、忽略的问题都会加倍体现。建议在写三元函数前一定要想清楚。
15、如果函数看来需要两个、三个或三个以上的参数，就说明其中一些参数应该封装为类了。从参数创建对象，从而减少参数数量，看起来像是在作弊，但实则并非如此。当一组参数被共同传递，这些参数往往就是该有自己名称的某个概念的一部分。
16、给函数取个好的名字，能较好地解释函数的意图，以及参数的顺序和意图。对于一元函数，函数和参数应形成一种非常良好的动词/名词对形式。
17、把参数名词编码成函数名，可以大大减轻记忆参数顺序的负担。
18、函数承诺只做一件事，但还是会做其他被藏起来的事。有时，他会对自己类中的变量做出未能预期的改动。有时，他会把变量搞成向函数传递的参数或是系统全局变量。无论哪种情况，都是具有破坏性的，会导致古怪的时序性耦合及顺序依赖。
19、应避免使用输出参数。如果函数必须要修改某种状态，就修改所属对象的状态。
20、函数要么做什么事，要么回答什么事，二者不可得兼。函数应该修改某对象的状态，或是返回该对象的有关信息。
21、从指令函数返回错误码轻微违反了指令与询问分隔的规则。它鼓励了在if语句判断中把指令当做表达式使用。这不会引起动词/形容词混淆，但却导致更深层次的嵌套结构。当返回错误码时，就是在要求调用者立刻处理错误。另一方面，如果使用异常代替返回错误码，错误处理代码就能从主路代码中分离出来，得到简化。
22、Try/catch 代码块丑陋不堪。它们搞乱了代码结构，把错误处理与正常流程混为一谈。最好吧try/catch代码块的主题部分抽离出来，另外形成函数。
23、函数应该只做一件事。错误处理就是一件事。因此，处理错误的函数不该做其他事。这意味着如果关键字try在某个函数中存在，它就该是这个函数的第一个单词，而且在catch/finally代码块后面也不该有其他内容。
24、返回错误代码通常暗示某处有个类或是枚举，定义了所有错误码。依赖磁铁：其他许多类都得导入和使用它。使用异常代替错误码，新异常就可以从异常类派生出来，无需重新弄编译或重新部署。
25、重复可能是软件中一切邪恶的根源。许多原则与实践规则都是为控制与消除重复而创建。
26、每个函数、函数中的每个代码块都应该有一个入口、一个出口。遵循这些规则，意味着在每个函数中只该有一个return语句，循环中不能有break和continue语句，而且永永远远不能有任何goto语句。
27、赞成结构化编程的目标和规范，但对于小函数，这些规则助益不大。只有在大函数中，这些规则才会有明显的好处。所以，只要保持函数短小，偶尔出现的return、break或continue语句没有坏处，甚至还比单入单出更具有表达力。另一方面，goto只在大函数中才有道理，所以应该尽量避免使用。

• 以上内容是看《代码整洁之道》[美·马丁] 第三章 函数 的总结
• 阅读原文：https://blog.csdn.net/c_lanxiaofang/article/details/79262958