1. 短小
- 函数尽可能的维持在一屏可见的范围内。20行封顶代码最好。代码短小除了阅读轻松外，更便于理解，出错的概率也比较小。
2. 只做一件事情
- 我们常常期望函数具有可扩展性，貌似有点不一致？？？
3. 每个函数一个抽象层级
- 每个函数都对应一个抽象层级
- 函数由相同抽象层级的其他函数组成
自顶向下读代码：向下规则
4. switch语句
xxxx
5. 使用描述性名称
- “如果每个函数都让你感到深合己意，那就是整洁代码”
- 长而具有描述性的名称比短却费解的名称要好
- 使用某种命名约定，让函数名称中的多个单词容易阅读，然后使用这些单词给函数取个能说清其功用的名称
- 命名方式上下保持一致
6. 函数参数
- 函数参数最好越少越好，理想个数为0，其次1个，再次2个，尽量避免3个，有足够多的理由才能使用3个以上参数
- 参数会带来太多的概念性。（入参，出参）
- 参数会是测试的难度加大，难以保证测试覆盖度
- 一元函数的普遍形式。 1. 询问参数，2. 转换参数 3. 事件
- 不要将flag作为参数传递给函数，因为这显而易见的告知他人这个函数不只是做一件事情（false时一件事，true时另外一件事情）
- 二元函数 可以通过一些方法转化为一元函数，比如写成某种对象的成员函数
- 多元参数，适时进行封装
- 无副作用
还是只能做一件事情，但即使函数承诺只做一件事情，但还是会做其他被藏起来的事。
如果函数名只是一个掩护，而在实现中做了与描述功能不相符或者额外的其他事情，但这是极其危险的。强调名副其实！
避免使用输出参数，可以使用修改类的属性方式替换。
7. 分隔指令与询问
- 函数要么做什么事，要么回答什么事，二者择其一
8. 使用异常替代返回错误码
- 返回错误码可能会导致深层次的嵌套结构。因为需要做错误处理
- 使用try catch，可以将错误代码从主路径中分离出来
9. 抽离try/catch代码块
- 不要在主路径中使用try/catch， 会导致代码结构混乱
- 可以抽离出来封装成函数
10. 错误处理就是一件事
- 这意味着，处理错误的函数不该做其他事情，所以这个函数的第一个单词应该是try，另外catch/finally后面也不应该有其他内容。
11. 错误码的依赖
- 返回错误码通常暗示有某个类或者枚举定义了所有的错误码。
- 那么其他使用这些错误码的类就需要去include这个类/头文件，那么如果需要添加新的错误码
- 就可能需要所有引用过的类都需要重新编译
- 如果使用异常代替错误码，新的异常可以直接从异常类中派生出来，无需重新编译和重新部署。
12. 别重复自己
- 减少重复代码
13. 结构化编程
- 遵循一个入口，一个出口原则，每个函数只能有一个return，循环中不能有break或continue语句，永远不能有goto
- 这只是针对大函数，对于小函数没有太大关系
- 另外DSP编程中循环中的break和continue除了破坏代码结构之外，增加了跳转破坏函数的并行性
- 所以函数只要保持短小，偶尔出现的return, break 或 continue语句没有坏处，甚至还比单入单出原则更有表达力。
- 另外，沟通只在大函数中才有道理，所以尽量避免使用