Clean-Code:函數

短小：

函數的第一規則是短小，第二規則還是短小，

很明顯作者將短小放到第一個列出來的位置。說明對於函數而言，短小的重要性不言而喻。

可是函數多少行纔算短小呢？

代碼大全上說一個函數理論上應該小於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種。

針對這方面的介紹可以去看下策略模式。