千万不要把 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%确认你想去写出无法维护很难阅读的代码。
【更新2011/9/8】当然,别的参数也会有一样的问题,比如:new Textbox(300, 100, false, true);
中的300 和 100,不知道是坐标还是长宽,只不过,一般长度或坐标这样的参数都不会被hard code,都会有变量名,而bool这种参数经常性地被传成true 和 false。 bool参数表现得更为明显一些罢了。
所以,程序中不要出现magic number,true/false 也是一种 magic number。但是,我想告诉大家,从API设计的角度来说,你无法强制调用者用常量来取代true/false,定义成枚举类型是最好的选择。
最后,如果你想设计一个好的API,强烈推荐你读一下Nokia的Qt的《API Design Principles》,本文就是其中的“Boolean Trap”。
(全文完)
(转载本站文章请注明作者和出处 宝酷 – sou-ip ,请勿用于任何商业用途)
《千万不要把 bool 设计成函数参数》的相关评论
void repaint(bool immediate);
有谁会看不懂? 至于调用API的人非要把代码写成别人看不明白的样子,关API提供者什么闲事啊.
相反, 你调用API的时候, 是void repaint(bool immediate)更清楚还是
void repaint(PAINT immediate)更明白?
实际上是枚举PAINT 的命名有问题。
枚举似乎太麻烦了,还好vs鼠标放上去就有提示 还是挺方便的。 不过我个人还是比较同意的 尽量别用bool
如此说来,跟软编码硬编码还有所牵扯
哈哈哈, objC就木有这个问题,每个变量都有名字啊。
正解!
这篇文章让我在欢乐中又有收获哈~
危言耸听了点吧。。。
使用 VC 助手的无压力飘过
标题党加上可读性的bad smell……以为这样就能逃过documentation hell & naming resposibility么,太甜了。
“看了文档才知道”——教育咱不看是活该233。
算了。
转个自己的旧吐槽:http://tieba.baidu.com/p/1150865423?pid=13331299045&cid=0#13331299045,关于Qt的API Design Principles的The Convenience Trap一节。
感觉true,false作为参数并没有什么问题,事实上我个人也喜欢(无论是在C中或其他地方),不过python的做法似乎更好
widget.repaint(immediate = True)
这样就很好理解了
所以我还是喜欢传一个object作为参数。这样读起来方便多,用起来也很爽。比如JS: someFunction({ title:’a’,content:’b’ });
其实只要是用字面常量(literal const)而不是变量或命名常量作为实参调用方法, 不管是什么(基本的)数据类型, 都存在这个问题.
一般习惯在setxxx的时候,可能会将bool设为参数…过多的标识符会带来极大的阅读不便~
很大程度上论述的其实还是magic number的问题
不能苛同楼上某些人说objc就完美解决了这个问题。一个函数就应该只做一件事。如果允许bool参数的话,显然要加一个if去判断,这样函数的行为就不可知了,很容易有副作用。 就象 [self performSelector: onThread: withObject: waitUntilDone:] 一个不小心就把waitUntilDone写成yes了,然后线程就锁住了。还不如另写一个函数明白些。
这种用true和false来作参数的方式与汇编里面经常用到的“标志位”很类似,程序可读性对于程序员本身来说也是个头疼的问题。
国内程序员基本上用IDE,所以这些问题不算大问题
那是你二逼了… = = @atusoft
@dabenxiong
正解+1
感觉是楼主读完这篇再用自己的话复述一遍,连代码都一样
http://ariya.ofilabs.com/2011/08/hall-of-api-shame-boolean-trap.html
@宝酷
这是因为immediate变量这个名字取得不好,改成bIsImmediate或isImmediate就会好些。
《写出可读代码的艺术》中建议,遇到这种特殊情况,Python 可以这么调用:
connect(user, pass, encryption=True)
C 类语言就这样
connect(user, pass, /*encryption=*/ true)
以前还没真没有注意到这个问题!!看来以后还是要多学东西啊!!
做期末大作业遇到过,坑了我半天吧!
Nokia的Qt的《API Design Principles》 中的链接是: http://wiki.qt.io/API_Design_Principles ….
说阅读代码困难,你只是需要一个能显示函数签名那个变量叫什么的 IDE 而已。
没事别用 notepad.exe 写代码还抱怨看不懂,那活该看不懂。
bool FuncClass::onDataCallBack( SocketClient &client, bool dns,bool compleled )
每天都在猜谜
主要还是魔数问题,如果不是使用vs等ide,传参最好是传入变量即可解决这个问题
var name=’tim’;
var age =12;
var p = new People(name,age);
这些东西你想那多少拿多少,明天来UC上班