短小：

函数的第一规则是短小，第二规则还是短小，

很明显作者将短小放到第一个列出来的位置。说明对于函数而言，短小的重要性不言而喻。

可是函数多少行才算短小呢？

代码大全上说一个函数理论上应该小于50行，我认为这个数字有点大了，我比较同意Bob的看法，”20行左右的代码为佳”

代码块和缩进：

代码块和缩进的规则很多，不过有很多格式化工具可以为我们做这种事情，

比如在vs2010中，就可以ctrl+ A(全选) ，Ctrl+K+F(格式化)

只做一件事：

函数应该只做一件事，做好这件事，只做一件事。

基本上这点大家都知道，如果一个函数做了多个事就代表有多个原因可以导致函数被修改。

但是难的是这一件事是什么？，

比如代码：

public static string RenderPageWithSetupAndTeardowns(
    PageData pageData,Boolean isSuite) throw Exception
{
    if(isTestPage(pageData))
    {
        includeSetupAndTeardownPages(pageData,isSuite);
    }
    return pageData.getHtml();
}

看起来好像做了三件事：

1：判断是否为测试页

2：如果是，则包含设置和分析步骤。

3：返回Html。

那么RenderPageWithSetupAndTeardowns函数是做了一件事，还是三件事呢？

Bob 提供了”To”(要)原则，也就是以To起头段落来描述这个函数。

要(To) RenderPageWithSetupAndTeardowns，检查页面是否为测试页，如果是测试页，就包含设置和分析步骤，无论是不是测试页，都返回HTML。

这三件事情都处于一个抽象层次上，所以RenderPageWithSetupAndTeardowns做了一件事。

判断函数只做了一件事还有另一个方法：看能否再拆出一个函数

我经常用的就是这第二个方法，不断的抽取函数，直到不能抽取为止，那么就可以保证函数只做了一件事了。

函数分布：

自顶向下读代码，向下规则。

一般读代码都是从上到下，从左到右，如果函数的分布也能符合这个原则的话，那么阅读起来就比较轻松了。比如下面的代码：

private void Method1()
{
    Method2();
}

private void Method2()
{
    Method3();
}

private void Method3()
{
    ...
}

阅读起来非常的轻松，看到这样的代码，心里也比较舒服。

困难的是函数的调用时多个，可能Method1调用Method2，Method2调用Method3,然后Method3调用Method2.什么的，就是说，函数的调用存在交叉

在上面的图中，顺序可能是1 2 4 3 5.也可以是1 2 3 4 5。

不过需要保持的一点就是调用的方法在前面，被调用的方法在后面。这样就能保证代码是从上往下看的了。

Switch语句：

很多设计模式都是针对Switch语句，比如抽象工厂，策略，状态 等。

原因也比较简单：switch语句天生做了N件事，也就是引起switch语句变化的原因至少有N种。

针对这方面的介绍可以去看下策略模式。