通常來說，我認為在設計一個函數原型的時候，應該盡量避免使用布爾類型的參數，除非函數名稱能十分清楚的將這個參數的意思表達出來。

我并沒有想教你做事，但是請聽我細說

先舉兩個正面的例子，有一個 API 函數 EnableWindow，它用來啟用或禁用一個窗口。它的第二個參數是一個布爾型參數，如果此參數傳入 TRUE，則調用此函數會將指定的窗口啟用，傳入 FALSE，則禁用窗口。

另外一個是 ShowScrollBar 的最后一個參數，它也是一個布爾型的。它的含義也十分明顯，如果傳入 TRUE，則表明將會顯示滾動條，如果傳入 FALSE，則會將滾動條隱藏。

這兩個例子中，布爾型參數的含義都清楚的體現在了函數的名稱中，是一個良好設計。

但下面的例子就沒那么顯而易見了。

我們看看這個函數 CreateEvent，它的第一個參數是布爾型的，但如果不查看函數的文檔，則開發者很難想象這個參數具體的作用是什么。看了文檔之后，才會明白：這個參數用來控制是否創建一個自動重置的事件對象。更進一步地，到底是傳入 TRUE 還是 FALSE 來創建一個自動重置對象呢？每次當我調用這個函數的時候，我都只能老老實實的翻開函數文檔認真閱讀，才知道具體應該傳入什么布爾值。

我認為，這個參數應該被設計為一個 DWORD 或者，如果更優雅一些的話，應該設計為一個枚舉，類似于：EVENTTYPE_AUTORESET 和 EVENTTYPE_MANUALRESET，這樣就一眼可以看出來參數的含義了。

更加糟糕的是，CreateEvent這個函數中，總共有兩個布爾型參數，你需要弄明白這些布爾值的含義，還得小心不要記錯順序了，這可太糟了。

另外一個反面例子是：StreamReader(Stream, bool) 這個函數，我想問問聰明的你，如果先不看函數文檔的話，你能猜到它的第二個參數是什么意思嗎？

總結

以上只是我的個人看法，怎么設計你的函數害得你自己決定。
但，為什么不讓生活變得更美好一些呢？
幫助他人(你代碼的閱讀者)，善待自己(三個月后的自己)。