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