函数设计心得：尽量避免布尔型参数

布尔型参数"/>

函数设计心得：尽量避免布尔型参数

通常来说，我认为在设计一个函数原型的时候，应该尽量避免使用布尔类型的参数，除非函数名称能十分清楚的将这个参数的意思表达出来。

我并没有想教你做事，但是请听我细说

先举两个正面的例子，有一个 API 函数 EnableWindow，它用来启用或禁用一个窗口。它的第二个参数是一个布尔型参数，如果此参数传入 TRUE，则调用此函数会将指定的窗口启用，传入 FALSE，则禁用窗口。

另外一个是 ShowScrollBar 的最后一个参数，它也是一个布尔型的。它的含义也十分明显，如果传入 TRUE，则表明将会显示滚动条，如果传入 FALSE，则会将滚动条隐藏。

这两个例子中，布尔型参数的含义都清楚的体现在了函数的名称中，是一个良好设计。

但下面的例子就没那么显而易见了。

我们看看这个函数 CreateEvent，它的第一个参数是布尔型的，但如果不查看函数的文档，则开发者很难想象这个参数具体的作用是什么。看了文档之后，才会明白：这个参数用来控制是否创建一个自动重置的事件对象。更进一步地，到底是传入 TRUE 还是 FALSE 来创建一个自动重置对象呢？每次当我调用这个函数的时候，我都只能老老实实的翻开函数文档认真阅读，才知道具体应该传入什么布尔值。

我认为，这个参数应该被设计为一个 DWORD 或者，如果更优雅一些的话，应该设计为一个枚举，类似于：EVENTTYPE_AUTORESET 和 EVENTTYPE_MANUALRESET，这样就一眼可以看出来参数的含义了。

更加糟糕的是，CreateEvent这个函数中，总共有两个布尔型参数，你需要弄明白这些布尔值的含义，还得小心不要记错顺序了，这可太糟了。

另外一个反面例子是：StreamReader(Stream, bool) 这个函数，我想问问聪明的你，如果先不看函数文档的话，你能猜到它的第二个参数是什么意思吗？

总结

以上只是我的个人看法，怎么设计你的函数害得你自己决定。
但，为什么不让生活变得更美好一些呢？
帮助他人(你代码的阅读者)，善待自己(三个月后的自己)。

最后

Raymond Chen的《The Old New Thing》是我非常喜欢的博客之一，里面有很多关于Windows的小知识，对于广大Windows平台开发者来说，确实十分有帮助。
本文来自：《Try to avoid having BOOL function parameters》