小論「Boolean參數做爲入參」的函數

《Clean Code》一書中對於如何寫好函數有着很動人的描寫，其中對於函數參數的建議有以下兩點：

• 函數參數的數量應該儘量少
• 給一個一元函數傳入bool類型的參數很「罪惡」

昨天在瀏覽Hacker News的時候剛好發現一篇文章提到了上面的第2點，即有關「Boolean參數」的討論。因此結合此篇文章，略做小結加深印象。

對於《Clean Code》在3.6.2當中的描述，給一個函數傳入Boolean參數其實也就是很明顯的宣稱該函數不止作一件事情，這和該書當中所倡導的「函數只作一件事情」顯然是相違背的。儘管如此，就並無豐富編碼經驗的本身而言，這一點多少是沒有讓我很是「印象深入」。相反的，我曾經還極其認真的寫過這樣的函數，由於那個函數如此實現看起來多少有些風韻，可以"以一敵雙"不是很是cool的作法嘛，而且那個函數自己很短小，本身壓根沒有想過把它分做兩個函數來寫—— 或許在以後，碰到相似的狀況時就會略做斟酌了。

如上提到的文章，標題爲「Boolean parameters to API functions considered harmful」。顯然地，做者也是提到了給一個函數塞入Boolean參數是一種不可取的作法，由於當一個函數做爲API的時候，使用者很難將true/false與具體API當中實現的功能對應起來，如文中的舉例：

// open的第三個參數爲Boolean類型，肯定是否以async/sync的方式打開，可是option當中的值未必與open內部的操做相對應。    
_xhr.open(options.type, options.url, options.sync);

// AddObserver的第三個參數爲Boolean類型，其對應的true/false具體意味着什麼顯得很模糊
mDocument->AddObserver(observer, "load", true);

而對其進行優化以後即可以這樣：

// 此時openAsync很明顯的告之了以async的方式打開。
xhr.openAsync(options.type, options.url)

// 接口AddWeakObserver提示了增添weak的Observer
mDocument.AddWeakObserver(observer, "load");

對好比上的兩個例子，後者看起來更爲清晰，其函數直接表達了接口的主要權責，這也是Clean Code一書當中所建議的作法。固然，對於這種作法是否是必定必要，就得因人而異，因各團隊而不一樣了。舉出反例來證實這種方式的沒必要要是很簡單的事，就好比做者文中的 setVisiblity(false)同樣。

總而論之，就我的而言，在函數命名與接口設計上面多做考慮，使代碼更爲天然和清晰是一件須要去追求和學習的事情。另外不得不提的是，當前的這種建議，僅僅對於本身略知的強類型語言C/C++/Java，其餘語言是否有所特殊之處，另當別論。