第三章 - 函数 - 读书心得

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语句没有坏处，甚至还比单入单出原则更有表达力。

- 另外，沟通只在大函数中才有道理，所以尽量避免使用