|
|
51CTO旗下网站
|
|
移动端

34 警告就是错误

《高效程序员的45个习惯:敏捷开发修炼之道》本书总结并生动地阐述了成为高效的开发人员所需具备的 45个习惯、思想观念和方法,涵盖了软件开发进程、编程和调试工作、开发者态度、项目和团队管理以及持续学习等几个方面。本节为大家介绍警告就是错误。

作者:钱安川/郑柯 译来源:人民邮电出版社|2010-03-04 08:57

34 警告就是错误

"编译器的警告信息只不过是给过分小心和过于书呆子气的人看的。它们只是警告而已。如果导致的后果很严重,它们就是错误了,而且会导致无法通过编译。所以干脆忽略它们就是了。"

当程序中出现一个编译错误时,编译器或是构建工具会拒绝产生可执行文件。我们别无选择--必须要先修正错误,再继续前行。

然而,警告却是另外一种状况。即使代码编译时产生了警告,我们还是可以运行程序。那么忽略警告信息继续开发代码,会导致什么状况呢?这样做等于是坐在了一个嘀嗒作响的定时炸弹上,而且它很有可能在最糟糕的时刻爆炸。

有些警告是过于挑剔的编译器的良性副产品,有些则不是。例如,一个关于未被使用的变量的警告,可能不会产生什么恶劣影响,但却有可能是暗示某些变量被错误使用了。

最近在一家客户那里,Venkat发现一个开发中的应用有多于300个警告。其中一个被开发人员忽略的警告是这样:

  1. Assignment in conditional expression is always constant;  
  2. did you mean to use == instead of = ? 

条件表达式中的赋值总为常量,你是否要使用==而不是=?

相关代码如下:

  1. if (theTextBox.Visible = true)  
  2. ... 

也就是说,if语句总是会评估为true,无论不幸的theTextBox变量是什么状况。看到类似这样真正的错误被当作警告忽略掉,真是令人感到害怕。

看看下面的C#代码:

  1. public class Base  
  2. {   
  3.   public virtual void foo()  
  4.   {  
  5.     Console.WriteLine("Base.foo");  
  6.   }  
  7. }  
  8.  
  9. public class Derived : Base  
  10. {  
  11.   public virtual void foo()  
  12.   {  
  13.     Console.WriteLine("Derived.foo");  
  14.   }  
  15. }  
  16.  
  17. class Test  
  18. {  
  19.   static void Main(string[] args)  
  20.   {  
  21.     Derived d = new Derived();  
  22.     Base b = d;  
  23.     d.foo();  
  24.     b.foo();  
  25.   }  

在使用Visual Studio 2003默认的项目设置对其进行编译时,会看到如此信息"构建:1个成功,0失败,0跳过"显示在Output窗口的底部。运行程序,会得到这样的输出:

  1. Derived.foo  
  2. Base.foo 

但这不是我们预期的结果。应该看到两次对Derived类中foo方法的调用。是哪里出错了?如果仔细查看Output窗口,可以发现这样的警告信息:

  1. Warning. Derived.foo hides inherited member Base.foo  
  2. To make the current member override that implementation,  
  3. add the override keyword. Otherwise, you' d add the new keyword. 

这明显是一个错误--在Derived类的foo()方法中,应该使用override而不是virtual。   想象一下,有组织地忽略代码中类似这样的错误会导致什么样的后果。代码的行为会变得无法预测,其质量会直线下降。

可能有人会说优秀的单元测试可以发现这些问题。是的,它们可以起到帮助作用(而且也应该使用优秀的单元测试)。可如果编译器可以发现这种问题,那为什么不利用它呢?这可以节省大量的时间和麻烦。

要找到一种方式让编译器将警告作为错误提示出来。如果编译器允许调整警告的报告级别,那就把级别调到最高,让任何警告不能被忽略。例如,GCC编译器支持-Werror参数,在Visual Studio中,开发人员可以改变项目设置,将警告视为错误。

对于一个项目的警告信息来说,至少也要做到这种地步。然而,如果采取这种方式,就要对创建的每个项目去进行设置。如果可以尽量以全局化的方式来进行设置就好了。

比如,在Visual Studio中,开发人员可以修改项目模板(查看.NET Gotchas [Sub05]获取更多细节),这样在计算机上创建的任何项目,都会有同样的完整项目设置。在当前版本的Eclipse中,可以按照这样的顺序修改设置:Windows→Preferences→ Java→Compiler→Errors/Warnings。如果使用其他的语言或IDE,花一些时间来找出如何在其中将警告作为错误处理吧。

在修改设置的时候,要记得在构建服务器上使用的持续集成工具中,修改同样的设置选项。(要详细了解持续集成,查看第87页习惯21。)这个小小的设置,可以大大提升团队签入到源码控制系统中的代码质量。

在开始一个项目的时候,要把相关的设置都准备好。在项目进行到一半的时候,突然改变警告设置,有可能会带来颠覆性的后果,导致难以控制。

编译器可以轻易处理警告信息,可是你不能。

将警告视为错误。签入带有警告的代码,就跟签入有错误或者没有通过测试的代码一样,都是极差的做法。签入构建工具中的代码不应该产生任何警告信息。

切身感受

警告给人的感觉就像……哦,警告。它们就某些问题给出警告,来吸引开发人员的注意。

平衡的艺术

虽然这里探讨的主要是编译语言,解释型语言通常也有标志,允许运行时警告。使用相关标志,然后捕获输出,以识别并最终消除警告。

由于编译器的bug或是第三方工具或代码的原因,有些警告无法消除。如果确实没有应对之策的话,就不要再浪费更多时间了。但是类似的状况很少发生。

应该经常指示编译器:要特别注意别将无法避免的警告作为错误进行提示,这样就不用费力去查看所有的提示,以找到真正的错误和警告。

弃用的方法被弃用是有原因的。不要再使用它们了。至少,安排一个迭代来将它们(以及它们引起的警告信息)安全地移除掉。

如果将过去开发完成的方法标记为弃用方法,要记录当前用户应该采取何种变通之策,以及被弃用的方法将会在何时一起移除。

【责任编辑:云霞 TEL:(010)68476606】

回书目   上一节   下一节
点赞 0
分享:
大家都在看
猜你喜欢

读 书 +更多

软件设计师考试全真模拟试题及解析

本书是按照全国计算机技术与软件专业技术资格(水平)考试《软件设计师考试大纲》的要求,参照《软件设计师教程》及近年来考试试题编写的,...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊