文档介绍：不存在免费午餐
“自由”特征是那些多余性错误的另一个来源。表面上,自由特征似乎是值得的,因为这只需要很少甚至不需要做任何努力就能跳过已有的设计。怎样才能比这更好呢?具有自由特征会带来很大的问题,尽管它们对产品的成败几乎从未起过任何关键的作用。正如我在上一节讲的,你应该把任何非关键特征看成是错误的来源。程序员向程序内增加自由特征是因为他们可以增加而不是因为他们必须增加。如果它不需要你付出任何代价,那为什么不增加一个特征呢?
啊!但是这是谬论。对于程序员来说,增加自由特征可能不费事,但是对于特征来讲,它不仅仅增多了代码,还必须有人为该特征写又档,还必须有人来测试它。不要忘记还必须有人来修改该特征可能出现的错误。
当我听到某个程序员说某特征是自由的,我就知道他没有花时间来考虑纳入该特征的真正代价。
不设自由特征
灵活性滋生错误
避免错误的另一条策略是排除设计中没有必要的灵活性。这个原则贯穿本书的始终。例如,在第一章,我使用了选择编译警告以避免出现冗余的和有风险的C语言惯用语。在第2章,我把ASSERT定义为一条语句来防止在表达式中错误地使用宏。在第3章,我使用了断言来捕获传递给FreeMemory的NULL指针,即使使用NULL指针调用free函数是合法的,我也这么做了。……我可以列出每一章的例子。
灵活设计的问题在于,设计越灵活,就越难发觉错误。还记得我在第5章中针对realloc所强调的那几点吗?你几乎可以扔掉realloc的任何输入集,可它仍将继续执行,但是它可能并没按你所希望的去执行。更糟糕的是,由于函数很灵活,因此不能插入有意义的断言验证输入的有效性。但是,如果把realloc分成为扩展、收缩、分配、释放存储块四个专门函数,则确认函数变元就要容易得多了。
除了过度灵活的函数之外,还应该时刻警惕着过度灵活的特征。由于灵活的特征可能产生一些没有预料到的“合法”情况,你可能会认为这些情况不需要测试甚至认为这就是合法的,因此,灵活特征同样很棘手。
例如,当我为Apple的Excel和新的Macintosh Ⅱ机器的Excel增加彩色支持程序时,我要从Windows Excel上移植一段代码,该代码允许用户指定显示在电子表格格子内的正文颜色。例如,向一个格子内增加颜色,你应该选择已有的格子形式,如下所示($1,):
$#,##
并且在前面加上颜色声明。为了显示蓝色,用户就需要将上面的形式改为:
[blue]$#,##
如果用户写了[red],那么数据以红色显示,如此等等。
Excel的产品说明非常清楚,颜色说明应放在数据形式的开始处,但是当我移植了这个特征打开始测试代码时,我发现下面的所有形式都工作
$#,##[blue]
$#,##[blue]
$[blue]#,##
你可以将[blue]放在任何地方。当我向原来的程序员询问这是个错误还是个特征时,他说颜色声明可以放在任意位置“仅仅是脱离了语法分析循环。”他不认为允许一点点额外的灵活性是个错误,当时我也那么认为,于是代码就那样保留下来了。然而,回顾一下,我们不应该允许这个额外的灵活性。
不久测试组发现了六个微妙的错误,最终所有这些错误都起因于格式的语法分析程序,因为它没有料想到会发现彩色说明处于格式中间的情况。但是我们没有通过删除没有必要的灵活性来改正这个错误(这需要增加一个简单的if语句),而只是改正了这些特定的错误,即改正了错误的症状,从而保留了任何人已不再需要的灵活性。时至今日,Excel仍允许将彩色说明置于你所希望的任何位置。
因此在你实现特征时要记住:不要使它们具有没有必要的灵活性,但是要容易使用。这两者是有差别的。
不允许没有必要的灵活性
移植的代码也是新代码
在把Windows Excel代码移植到Maxintosh Excel的过程中,我得到了这样一条教训,人们对这种移植过来的代码,总想少做些检查。毕竟这些代码是在原来的产品中测试过的。我在把移植代码交给测试组之前就应捕获Excel数字格式代码中的全部错误,但是我没有这么做。我只是把代码拷贝到Macintosh Excel,做了一些为把这些代码连接到项目中所必须的修改,然后临时测试了一下代码来验证它已被正确地连接起来了。我没有全面测试特征本身,因为我认为这已经测试过了。这是失策的,特别是在当时的情况下,Windows Excel本身也正处于开发阶段,这就更是失策。那正是Microsoft小组把修改错误推迟到产品周期的最后阶段那个时期。
实际上,不管你是怎样实现特征的,是从头开始设计实现,还是依据某个已有代码来设计实现的,你都有责任排除要加入到项目的那些代码中所存在的错误。如果Maci