代码简洁之启发

1.函数

F1: 过多的参数

函数的参数量应该少。没参数最好，一个次之，两个、三个再次之。三个以上的参数非常值得质疑，应坚决避免。

F2: 输出参数

输出参数违反直觉。读者期望参数用于输入而非输出。如果函数非要修改什么东西的状态不可，就修改它所在对象的状态好了。

F3: 标识参数

布尔值参数大声宣告函数做了不止一件事。它们令人迷惑，应该消灭掉。

2.重复

每次看到重复代码，都代表遗漏了抽象。重复的代码可能成为子程序或干脆是另一个类。将重复代码叠放进类似的抽象，增加了你的设计语言的词汇量。其他程序员可以用到你创建的抽象设施。编码变得越来越快，错误越来越少，因为你提升了抽象层级。
重复最明显的形态是你不断看到明显一样的代码，就像是某位程序员疯狂地用鼠标不断复制粘贴代码。可以用单一方法来替代之。

3.垂直分隔

变量和函数应该在靠近被使用的地方定义。本地变量应该正好在其首次被使用的位置上面声明，垂直距离要短。本地变量不该在其被使用之处几百行以外声明。
私有函数应该刚好在其首次被使用的位置下面定义。私有函数属于整个类，但我们还是要限制调用和定义之间的垂直距离。找个私有函数，应该只是从其首次被使用处往下看一点那么简单。

4.用命名常量替代魔术数

在代码中出现原始形态数字通常来说是坏现象。应该用良好命名的常量来隐藏它。术语“魔术数”不仅是说数字。它泛指任何不能自我描述的符号。

5.封装边界条件

边界条件难以追踪。把处理边界条件的代码集中到一处，不要散落于代码中。我们不想见到四处散见的+1 和-1 字样。看看这个来自FIT 的简单例子：

注意， level+ 1 出现了两次。这是个应该封装到名为nextlevel 之类的变址中的边界条件。

6.函数应该只在一个抽象层级上

函数中的语句应该在同一抽象层级上，该层级应该是函数名所示操作的下一层。这可能是最难理解和遵循的启发。尽管概念足够直白，人们还是很容易混淆抽象层级。

7. 在较高层级放置可配置数据

如果你有个已知并该在较高抽象层级的默认常量或配置值，不要将它埋藏到较低层级的函数中。把它作为较高层级函数调用较低层级函数时的一个参数。

8. 封装条件

如果没有if 或while 语句的上下文，布尔逻辑就难以理解。应该把解释了条件意图的函数抽离出来。

9. 名称

采用描述性名称

不要太快取名。确认名称具有描述性。记住，事物的意义随着软件的演化而变化，所以，要经常性地重新估量名称是否恰当。
看看以下代码。这段代码是做什么的？用了好名称的代码一目了然，而这样的代码却是符号和魔术数的大杂绘。

下面是这段代码应该写成的样子。代码片段实际上不如上段完整。但你还是能马上推断出它要做什么，而且很有可能依据推断出的意思写出遗漏的函数。魔术数不复神秘，算法的结构也足具描述性。

为较大作用范围选用较长名称

名称的长度应与作用范围的广泛度相关。对千较小的作用范围，可以用很短的名称，而对于较大作用范围就该用较长的名称。类似i 和j 之类的变量名对于作用范围在5 行之内的情形没问题。

避免编码

不应在名称中包括类型或作用范围信息。在如今的开发环境中， m_或f 之类前缀完全无用。类似vis_ （表示图形系统）之类的项目或子系统名称也属多余。当今的开发环境不用纠缠于名称也能提供这些信息。不要用匈牙利语命名法污染你的名称。