消除编译器警告是一个好主意吗？

在过去,我一直使用-Wall和其他gcc开关来消除我参与的项目的每个编译器警告.同样,在Perl中,我总是使用严格编程并使用警告(并且经常使用-T) )试图达到我能做到的最佳代码质量.据我所知,几年前,Perl搬运工小组努力使perl本身(Perl解释器)在gcc下干净利落地编译并启用了所有警告.显然他们觉得这对代码质量来说是一个好主意.我也明白,现在Perl程序员已经在他们的代码中添加了更多的警告Perl :: Critic,当他们违反Damian Conway的Perl最佳实践书(以及其他来源,我相信)中发现的最佳实践时会发出警告.

我一直对代码有一种很好的感觉,我用这种方式清理过,但有时我无法避免一些工作有点浪费的感觉.例如,在十多年前的我的介绍C类中,我被教导要启动我的main()函数,如下所示:

void main(void) {

这是最小的,只能在您没有返回值并且没有访问您的参数时使用.它在这种情况下工作正常,但gcc警告会让你知道这个函数应该是这样的:

int main(int args, char* argv) {

我必须在当天输入几百个未使用的int args,char*argv行.我真的让我的代码变得更好,或者只是把手指缩短了吗？

现在我在Eclipse中用Java编程,我们的项目有成千上万的警告.我想清理它们.其中一些特别难以理解和消除,但我正在慢慢学习.其中一些我必须处理编译器指令以抑制警告(通常用微小的方法来分解忽略警告的不良做法),但我也在寻找方法来处理这些警告.

这值得程序员的时间吗？如果您追踪每个编译器警告,项目真的会好得多吗？

如果没有别的,似乎将警告的数量减少到零是好的,这样严重的警告就不会在混乱中丢失.

注意:这个问题重复一遍

当然是.警告表示代码中可能存在错误.要么你修复它,要么你应该禁用警告 - 如果你不打算采取行动,警告只是阻止你检测何时出现新警告.

获取并保持代码无警告的最简单方法就是始终使用-Werror(Visual Studio中的/ WX)或等效代码进行编译.

这值得程序员的时间吗？如果您追踪每个编译器警告,项目真的会好得多吗？

是.即使是关于符号不匹配的微不足道的事情也会对代码生成和优化产生深远的影响.

我同意所有说"全部解决"的答案,但我仍然想提出一个相反的观点:

有一些遗留系统,其中一些(许多或所有)组件没有专门的维护者,系统的大部分基本上是未知的.修复此类未知代码中的编译器警告可能需要相当多的代码(因为对于每个警告,需要理解代码及其上下文)并引入可能的错误源(某些代码取决于未定义的行为).由于此类遗留系统很少有广泛的测试覆盖率,您甚至无法依靠测试来通知您回归.

C中有两个兼容原型.

int main(void)

和

int main(int argc, char **argv)

void main(void) 在技​​术上并不正确,尽管某些编译器可能会支持它作为标准的扩展.

因此,在您的特定情况下,您可以使用简短的声明main,如果符合,它将不会触发警告.

是.即使是微不足道的也值得一试.这就是原因.有些人,比如你提到的主要例子,可能不值得自己修理,但它们是合计的.从长远来看,大多数编译器警告都会为您带来直接的痛苦.它们是等待发生的错误(甚至现在发生).为了找到它们,您需要一种简单的方法来注意它们.如果您修复了所有警告,那么每个新警告都是一个红色标记,很容易被注意到.如果你修复了所有关键问题,但只留下一些类似"主要"问题,那么你将会错过新的关键问题.

哪个更容易记住？任何警告需要修复或者你昨天在这个代码库中有23个不相关的警告,所以如果你看到24你需要去看看？

在我工作的代码库中,我们告诉编译器在所有警告上生成错误.这迫使我们修复它们并使代码保持更好的形状.如果有一个真正不值得修复的警告,总会有#pragma让它消失.这样你仍然有一个明确的失败线.