34.警告就是错误

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

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

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

广告：个人专属 VPN，独立 IP，无限流量，多机房切换，还可以屏蔽广告和恶意软件，每月最低仅 5 美元

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

最近在一家客户那里，Venkat发现一个开发中的应用有多于300个警告。其中一个被开发人员忽略的警告是这样：Assignment in conditional expression is always constant;Did you mean to use == instead of = ?

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

相关的代码如下：

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

看看下面的C#代码：

Public class Base{

Public virtual void foo(){

Console.WriteLine(“Base.foo”); }}

Public class Derived ：Base{Public vitrual viod foo(){Console.WriteLine(“Derived.foo”); }}

Class Test{

Static void Main(string[] args){Derived d = new Derived(); Base b = d;d.foo();

b.foo();

}

}

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

但这不是我们预期的结果。应该看到两次对Derived类中foo方法的调用。是哪里出错了？如果仔细查看Ouput窗口，可以发现这样的警告信息：Warning.Derived.foo hides inherited member Base.fooTo make the current member overrode that implementation,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或第三方工具或代码的原因，有些警告无法消除。如果确实没有应对之策的话，就不要在浪费更多的时间了。但是类似的状况很少发生。

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

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

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