千万不要把 bool 当成函数参数

我们有很多 Coding Style 或 代码规范。 但这一条可能会经常被我们所遗忘，就是我们 经常会在函数的参数里使用bool参数，这会大大地降低代码的可读性。 不信？我们先来看看下面的代码。

当你读到下面的代码，你会觉得这个代码是什么意思？

widget->repaint(false);

是不要 repaint 吗？还是别的什么意思？

看了文档后，我们才知道这个参数是 immediate，也就是说，false 代表不立即重画，true 代码立即重画。

Windows API 中也有这样一个函数：InvalidateRect，当你看到下面的代码，你会觉得是什么意思？

InvalidateRect(hwnd, lpRect,  false);

我们先不说 InvalidateRect 这个函数名取得有多糟糕，我们先说一下那个 false 参数？ invalidate 意为 “让XXX无效”，false 是什么意思？ 双重否定？ 是肯定的意思？

如果你看到这样的代码，你会相当的费解的。 于是，你要去看一下文档，或是 InvalidateRect 的函数定义， 你会看到那个参数是 BOOL bErase，意思是：“是否要重画背景”。

这样的事情有很多，再看下面的代码，想把 str 中的 ”%USER%” 替换成真实的用户名：

str.replace("%USER%", user, false);   // Qt 3

TNND，那个 false 是什么意思？不替换吗？还是别的什么意思？

看了文档才知道，false 代表： “大小写不敏感的替换”。

其实，如果你使用枚举变量/常量，而不是 bool 变量，你会让你的代码更易读，如：

widget->repaint(PAINT::immediate);
widget->repaint(PAINT::deffer);

InvalidateRect(hwnd, lpRect, !RepantBackground);

str.replace("%USER%", user, Qt::CaseInsensitive); // Qt 4

如果对这个事不以为然的话，我们再来看一些别的示例，你不妨猜猜看看下面的代码：

component.setCentered(true, false);

这什么玩意儿啊？

看了文档你才知道，这原来是 setCentered(centered, autoUpdate);

new Textbox(300, 100, false, true);

这又是什么啊？

看了文档才知道，这是创建一个文本框，第三个参数是：“是否要滚动条”，第四个是：“是否要自动换行”。TNND！

这种情况还不算最差，看看下面的双重否定。

component.setDisabled(false);
filter.setCaseInsensitive(false)

再来一个，如果你读到下面的代码，相信你会和我一样，要么石化了，要么凌乱了。

event.initKeyEvent("keypress", true, true, null, null,
					false, false, false, false, 9, 0); 

看完这篇文章，我希望你再也 不要把bool为作为函数参数了。除非两个原因：

• 你 100% 确认不会带来阅读上的问题，比如 Java 的 setVisible (bool).
• 你 100% 确认你想去 写出迷一样的代码。

如果你想设计一个好的 API，强烈推荐你读一下 Nokia 的 Qt 的《API Design Principles》，本文就是其中的 “Boolean Trap”。

原文链接：http://coolshell.cn/articles/5444.html

评论

23 楼 naily 2012-11-23  

不敢苟同！

22 楼 fxrz12 2012-11-23  

是楼主孤陋寡闻了，boolean也可以拿来当做标识位，和函数名一点关系也没有，要不然就是用byte或者int作标识。
另外，像这样的重点难道没注释！这才是最坑爹的地方！楼主重点没搞对的说，所以你上面的一大堆几乎算是废话，不过也挺喜欢这样的废话，很有趣。

21 楼 AiAcc 2012-11-22  

。。。你这不搞笑嘛，你掉方法的时候，没参数名解释吗？如果参数的命名可读性高，你是掉方法，不是让你写方法

20 楼 satanultra 2012-11-22  

一般的ide都有函数提示啊，不能一概不用bool。毕竟有时候bool更简洁（不是说书写上是从表意上）。

19 楼 qq413041153 2012-11-22  

不该苟同啊 楼主,不说bool类型,就说随便一个参数,int string long map之类的,你不看函数说明,你就能知道是干嘛的? 好像不可能吧 在明确的定义也会产生分歧,最终办法还是写好文档 说明自己实现的初衷
以上尽是愚人短见

18 楼 jorneyR 2012-11-22  

写代码的时候，会觉得Cocoa的编码方式太烦人，但是当看的代码时，传统的Java，C，C++方式很郁闷，需要不停的看文档，而Cocoa的编码方式就体现出优势来了。

17 楼 kidneyball 2012-11-22  

kidneyball 写道

似乎原文的论点没有说到点子上，过于注重接口的可读性了。如果单纯从可读性来考虑，用boolean做参数可以用很多种简单的方法提高可读性。而用boolean做参数的真正不在于可读性，而在于：
。。。

不是说用boolean做参数就一定会产生控制耦合（例如setter），但控制耦合往往会产生boolean参数。因此看到boolean参数就最好特别留意一下，看看背后是不是跟着一堆控制耦合。

16 楼 kidneyball 2012-11-22  

似乎原文的论点没有说到点子上，过于注重接口的可读性了。如果单纯从可读性来考虑，用boolean做参数可以用很多种简单的方法提高可读性。而用boolean做参数的真正不在于可读性，而在于：

引用

5.3.2 不可取的内聚性
其余类型的内聚性，一般来说都是不可取的。其后果往往是产生一些组织混乱而又难以调
试和改进的代码。如果一个子程序具有不良的内聚性，那最好重新创建一个较好的子程序，而不要去试图修补它。知道应该避免什么是非常重要的，以下就是一些不可取的内聚性：

...

逻辑内聚性。当一个子程序中同时含有几个操作，而其中一个操作又被传进来的控制标志
所选择时，就产生了逻辑内聚性。之所以称之为逻辑内聚性，是因为这些操作仅仅是因为控制流，或者说“逻辑”的原因才联系到一起的，它们都被包括在一个很大的 if 或者 case 语句中，它们之间并没有任何其它逻辑上的联系。

举例来说，一个叫作 InputAll()的子程序，程序的输入内容可能是用户名字、雇员时间卡信息或者库存数据，至于到底是其中的哪一个，则由传入子程序的控制标志决定。其余类似的子程序还有 ComputeAll()，EditAll()，PrintAll()等等。这类子程序的主要问题是一定要通过传入一个控制标志来决定子程序处理的内容。解决的办法是编写三个不同的子程序，每个子程序只进行其中一个操作。如果这三个子程序中含有公共代码段，那么还应把这段代码放入一个较低层次的子程序中，以供三个子程序调用。并且，把这三个子程序放入一个模块中。

但是，如果一个逻辑内聚性的子程序代码都是一系列 if 和 case 语句，并且调用其它子程序，那么这是允许的。在这种情况下，如果程序的唯一功能是调度命令，而它本身并不进行任何处理，那么这可以说是一个不错的设计。对这种子程序的专业叫法是“事物处理中心”，事物处理中心往往被用作基础环境下的事件处理，比如，Apple Macintosh 和 Microsoft Windows。

......

控制耦合。如果一个子程序通过传入另一个子程序的数据通知它该作什么，那么这两个子
程序就是控制耦合的。控制耦合是令人不快的，因为它往往与逻辑内聚性联在一起，并且，通常都要求调用程序了解被调子程序的内容与结构。

摘自《完全代码》（《Code Complete》）第五章 《高质量子程序的特点》

15 楼 superheizai 2012-11-21  

我觉得这个东西并不是一定怎么样。在某种特定场景下，比如并非暴露出去的外部接口，只是内部使用的接口，为了维护保持代码整洁度，我个人认为可以这样用。比如：

 public String getTrueNum(){
  getNum(true);
}

 public String getFalseNum(){
   getNum(false);
 }

 private String getNum(Boolean)

14 楼 snow0613 2012-11-21  

可以使用常量来解决这个问题。

13 楼 陈碧滔 2012-11-21  

学习了！

12 楼 cicl 2012-11-21  

有点小题大做吧，现在有多少函数不读能直接看懂的？

11 楼 ray_linn 2012-11-21  

用命名参数就不好了

mfkvfn 写道

不知道你标题就的“不要把Bool函数参数”是指哪一种？是指“函数定义时不要使用bool类型的形参”？还是指“调用函数时不要传入bool类型的实参”？

作为方法的定义处，使用bool类型的形参并没有问题。
比如 public void repaint(boolean immediate)这种。反正自动代码补充时都会生成类似于widget.repaint(immediate)这样的代码人们很容易就能明白形参要表示什么意思。当然如果看它的文档(JavaDoc等)就更不会有问题了。

作为方法的使用处，如果怕使用widget.repaint(false)这样的实参以后，代码别人看不懂，只需要写成这样就可以了
boolean immediate=false;
widget.repaint(immediate);
boolean disabled=false;
component.setDisabled(disabled);

widget.repaint(immediate=false)

10 楼 mfkvfn 2012-11-20  

不知道你标题就的“不要把Bool函数参数”是指哪一种？是指“函数定义时不要使用bool类型的形参”？还是指“调用函数时不要传入bool类型的实参”？

作为方法的定义处，使用bool类型的形参并没有问题。
比如 public void repaint(boolean immediate)这种。反正自动代码补充时都会生成类似于widget.repaint(immediate)这样的代码人们很容易就能明白形参要表示什么意思。当然如果看它的文档(JavaDoc等)就更不会有问题了。

作为方法的使用处，如果怕使用widget.repaint(false)这样的实参以后，代码别人看不懂，只需要写成这样就可以了
boolean immediate=false;
widget.repaint(immediate);
boolean disabled=false;
component.setDisabled(disabled);

9 楼 kidneyball 2012-11-19  

xdwangiflytek 写道

方法加上详细的注释呗

加注释也有潜在问题的。一般情况下，如果这个方法的内部实现就是一个最外层的if套着两段完全不同的执行逻辑，那么在一开始你就会把它拆分成两个方法。比如说markForRepaint和repaintImmediately。人们之所以传入一个boolean作为控制标志，往往是因为方法的内部实现有大量公共部分，里面嵌着若干依赖于这个标志的分支。

这种方法最好在一开始的时候就想办法拆开，因为你在第一次开发时通常有比较充足的时间来重构，思路也比较连贯。否则在后续维护时，某人可能想复用这个方法，不过要做点修改。如果你本来就拆开了，他会按照你的思路来改。如果你本来就用boolean参数来控制分支，他可能就匆匆忙忙地想在其中加入一个新的分支，这时他会再加入一个新的boolean参数。如果这两个boolean参数完全独立那暂时还好，最怕是前一个为真时后一个完全无效，只有前一个为假时才有效。或者更痛苦的是前一个为真或假时，后一个的真假分别有细微的差异。然后再过段时间，又有人加进去一个boolean参数……

8 楼 kidneyball 2012-11-19  

spiniper 写道

这提出了一个问题，boolean类型的参数确实在此语义上存在歧义，而且注释又很难表述清楚，但是很多时候，写一个接口，让客户程序调用，又需要让客户程序在一定程度上决定api应该如何去执行，那么如果不使用boolean参数，那么我们如何解决这种开发需求？我想要了解你是如何使用一个或者某些替代性的方法来解决这种不使用boolean参数的方式。
换句话说，你提出了一个问题，但同时我希望你也能够给出一个解决这个问题的提案，这个提案不一定需要正确，但是多少给我们一个思考的方向。
顺便说一句，看见问题的人很多，但是解决问题的人很少。所以很多问题存在，大家也都知道，却都没有去解决，很可能跟着有关。

如果传入的boolean被当成普通数据来处理(例如直接保存到数据库中），其实是没有问题的。问题是绝大多数情况下，传入的boolean被用在if里作为分支条件，这就构成了在《Code Complete》里所谓的“控制耦合”，函数A通过传入某种标志来控制函数B的执行逻辑。这种耦合的问题是，除非你了解函数B的实现细节（或者有详细的文档），否则很难通过命名去表达清楚传入的控制标志会造成什么后果。而且随着B的执行逻辑不断修改，这个标志的实际效果往往会跟它的命名含义脱节。

解决的方法也有不少，只不过总不如写一个boolean的参数方便，所以很多人事到临头就会偷懒。包括：

1. 利用多态把分支结构转移到继承结构中。这需要有一定的架构能力。

2. 把boolean参数的true和false两种情况拆分成两个方法。（问题是如果公共部分较多，分支又不止一处，传入boolean参数就实在是太方便了。如果语言支持lambda特性重构起来就比较方便，否则就需要用模板模式或者策略模式来重构，相对比较麻烦）

3. 用enum类型（如果语言不支持，可以用命名常量代替，但效果不如enum）来做控制标志比用boolean要好。这种方案最常用，不过没有解决随着时间推移，标志的字面含义容易与实际行为脱节的问题。

7 楼 justjavac 2012-11-16  

spiniper 写道

原来不是原创，是我2了

陈浩哥的。

6 楼 spiniper 2012-11-16  

原来不是原创，是我2了

5 楼 haoel 2012-11-16  

请注意出处：http://coolshell.cn/articles/5444.html 谢谢

4 楼 spiniper 2012-11-16  

这提出了一个问题，boolean类型的参数确实在此语义上存在歧义，而且注释又很难表述清楚，但是很多时候，写一个接口，让客户程序调用，又需要让客户程序在一定程度上决定api应该如何去执行，那么如果不使用boolean参数，那么我们如何解决这种开发需求？我想要了解你是如何使用一个或者某些替代性的方法来解决这种不使用boolean参数的方式。
换句话说，你提出了一个问题，但同时我希望你也能够给出一个解决这个问题的提案，这个提案不一定需要正确，但是多少给我们一个思考的方向。
顺便说一句，看见问题的人很多，但是解决问题的人很少。所以很多问题存在，大家也都知道，却都没有去解决，很可能跟着有关。