不要忽略警告

北大青鸟大学城校区logo 北大青鸟大学城校区
招生简章校园环境师资力量就业明星招生问答软件工程师北京大学学历学员项目联系我们 报名通道

免费在线咨询通道>>

免费在线报名通道>>

北大青鸟报名电话
当前位置:北大青鸟 > 北大青鸟程序人生 >

不要忽略警告

标签:   分类:北大青鸟程序人生

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

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

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

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

最近在一家客户那里,、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 Bass

{

public virtual void foo()

{

console.writeline{"Base.foo")

}

}

public class berived :Bases

{

public virtual wold foo{}

{

Console.writeline (“Drrived.foo");

}

}

class Test

{

Static viod Main {string[] args;

Derived d=new Derived();

Base b=b;

d.foo();

b.foo();

}

}

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

Derived.foo

Base.foo

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

warning . Derived.foo hides inherrited member base.foo

To make the current member override that implementation

add the override , otherwise,you'd add the new keyword,

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

可能有人会说优秀的单元测试可以发现这些问题。是的,它们可以起到帮助作用(而且也应该使用优秀的单元测试)。可如果编译器可以发现这种问题,那为什么

不利用它呢?这可以节省大量的时间和麻烦。要找到一种方式让编译器将警告作为错误提示出来。如果编译器允许调整警告的报告级别,那就把级别调到最高,让任何警告不能被忽略。例如,Gcc编译器支持一werror参数,在Visual Studio中,开发人员可以改变项目设置,将警告视为错误。

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

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

在修改设置的时候,要记得在构建服务器上使用的持续集成工具中。修改同样的设置选项。这个小小的设置·可以大大提升团队签入到源码控制系统中的代码质量。

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

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

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

切身感受

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

平衡的艺术

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

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

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

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

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

若有疑问请拨打北大青鸟咨询热线:010-80146691或点击免费在线咨询!
  • xml地图 网站地图 招生简章 合作企业 学员项目 联系我们
  • 关闭窗口