《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，其他语言是否有所特殊之处，另当别论。