短小
- 20世纪80年代常说，函数不该长于一屏。
那时候一屏只有20行，80列。
现在能显示大概100行，150个字符，但是函数也不应该占满屏幕，20行封顶最佳。 - 代码块和缩进
if语句、else语句、while语句等，其中代码块应该只有一行。该行大抵应该是一个函数调用语句。
这也意味着函数不应该大到足以容纳嵌套结构。所以，函数的缩进层级不该多于一层或两层。
只做一件事
- 如果函数只是做了该函数名下同一抽象层上的步骤，则函数还是只做了一件事。
- 要判断函数是否不止做了一件事，还有一个方法，就是看是否能再拆出一个函数，该函数不仅只是单纯地重新诠释其实现。
- 只做一件事的函数无法被合理的切分为多个区段。
每个函数一个抽象层级
函数中混杂不同的抽象层级，往往让人迷惑。一旦细节和基础概念混杂，细节就会在函数中纠结起来。
要让每个函数后面都跟着位于下一抽象层级的函数。
switch语句
问题：
- 太长，当出现新的条件时，还会变得更长
- 不止做了一件事
- 违反了单一权责原则
- 违反了开闭原则，每当添加新类型时，就必须修改。
解决方案：
将switch语句埋到抽象工厂底下。
使用描述性的名称
- 函数越短小、功能越集中，就越便于取个好名字。
- 别害怕长名称。
- 别害怕花时间取名字。
- 选择描述性的名称能理清关于模块的设计思路，并帮助改进之。追索好名称，往往导致对代码的改善重构。
- 命名方式要保持一致。
函数参数
最理想的参数数量是零，其次是一，再次是二，应尽量避免三参数函数。
- 参数不易对付。
它带有太多概念性。以StringBuffer为例，作为参数传递时，读者每次看到都得翻译一遍。参数和函数名处于不同的抽象层级。 - 参数让测试变的困难。
如果参数多余两个，测试覆盖所有可能的组合让人生畏。 - 输出参数比输入参数还要难以理解
信息通过参数输入函数，通过返回值从函数输出。尽量不要让信息通过参数输出。
一元函数的普遍形式
向函数传入单个参数有两种极普遍的的理由。
你也许会问关于那个参数的问题。也可能是操作参数，将其转换为其他什么东西，再输出之。
还有一种不普遍但极有用的单参数函数形式，事件。这种形式，有输入参数无输出参数。小心使用这种形式。
尽量避免编写不遵循这些形式的一元函数。例如，void includeSetupPageInto(StringBuffer pageText)。对于转换，应该使用返回值，而不应该使用输出参数。StringBuffer transform(StringBuffer in)要比void transform(StringBuffer out)强，它遵循了转换的形式。
标识参数
向函数传入布尔值是丑陋的做法。它直接告诉我们这个函数不止做一件事，传入true将会这样做，传入false则会那样做。
二元函数
尽管有些时候两个参数刚好。比如Point p = new Point(0,0)，笛卡尔点天生就有两个参数。但是这是因为这两个参数是单个值的有序组成部分。
其他的就不好了，即使是如assertEquals(expected,actual)，这样的二元函数也有问题。你会经常搞错这两个参数的位置。这两个参数没用自然的顺序。
尽量利用一些机制把二元函数转换成一元函数。例如，writeFiled(outputStream,name)，可以把writeField方法写成outputStream的成员函数，从而能这样用：outputStream.writeField(name)。或者，也可以把outputStream写成当前类的成员变量，从而无需再传递它。还可以分离出类似FieldWriter的新类，在其构造器中采用outputSteam，并且包含一个write方法。
三元函数
排序、琢磨、忽略的问题都会加倍体现。
当然也有一些函数写成三参数还是可以不错的。
参数对象
如果函数看来需要两个、三个、或三个以上参数，就说明其中一些参数应该封装为类类。当一组参数被共同传递，往往就是该有自己名称的某个概念的一部分。
参数列表
有时，我们需要向函数传入数量可变的参数。例如，String.format方法。
但是这个方法实则是二元函数。
动词与关键字
给函数取个好名字，能很好的解释函数的意图，以及参数的顺序和意图。把参数的名称编码成函数名。例如write(name)和writeField(name)，它告诉我们name是一个field，assertEqual()改成assertExpectedEqualsActual(expected,actual)会好些。这大大减轻了记忆参数顺序的负担。
