消除编译器警告是个好主意吗？
在过去，我使用-Wall和其他开关为gcc消除了我所参与的项目的每一个编译器警告。类似地，在Perl语言中，我总是使用use strict和use warnings (通常也是-T )进行编程，以尽可能获得最佳代码质量。据我所知，几年前，Perl门户小组努力使perl本身( Perl解释器)在启用了所有警告的情况下在gcc下干净地编译。显然，他们觉得这是一个提高代码质量的好主意。我还了解到，现在Perl程序员已经使用Perl::Critic在他们的代码中添加了更多警告，当他们违反Damian Conway的Perl best practices一书中的最佳实践时，Perl：：Critic会发出警告(我相信来自其他来源)。
我总是对我以这种方式清理的代码有一种很好的感觉，但有时我无法避免一些工作有点浪费的感觉。例如，在十多年前的C语言入门课程中，我被教导要像这样启动main()函数：
void main(void) {这是最小的，只有当你没有返回值并且没有访问你的参数时才能使用。在这种情况下，它工作得很好，但gcc警告说，这个函数实际上应该是这样的：
int main(int args, char* argv) {我以前肯定输入了几百个未使用的int args，char* argv行。我真的让我的代码变得更好了吗，或者只是让我的手指变短了？
现在我在Eclipse中用Java编程，我们的项目有成千上万的警告。我想把它们清理干净。其中一些特别难以理解和消除，但我正在慢慢地学习。其中一些我不得不用编译器指令来抑制警告(通常是在很小的最小方法中，以消除忽略警告的糟糕做法)，但我也在寻找处理这些警告的方法。
这值得程序员花时间吗？如果你跟踪每一个单独的编译器警告，一个项目真的会更好吗？
如果没有其他事情，将警告的数量减少到零似乎会很好，这样严重的警告就不会在混乱中迷失。
注释：复制this question
回答 13
Stack Overflow用户
发布于 2009-02-04 16:57:23
是的，当然。警告是代码中可能存在错误的指示。要么修复它，要么禁用警告--如果您不打算对它采取行动，那么使用警告只会阻止您检测到何时出现新的警告。
获取并保持代码无警告的最简单方法是始终使用-Werror ( Visual Studio中的/WX)或等效的代码进行编译。
Stack Overflow用户
发布于 2009-02-04 17:12:58
我同意所有的答案，说“解决他们全部”，但我仍然想提出一个相反的观点：
有一些遗留系统，其中一些(许多或所有)组件没有专门的维护者，系统的大部分基本上是未知的。修复这种未知代码中的编译器警告可能需要相当多的代码(因为对于每个警告，代码及其上下文都需要被理解)，并引入了可能的错误来源(一些代码取决于未定义的行为)。而且，由于这样的遗留系统很少有广泛的测试复盖率，您甚至不能依靠测试来通知您回归。
Stack Overflow用户
发布于 2009-02-04 17:01:31
在C中，main有两个兼容的原型。
int main(void)和
int main(int argc, char **argv)void main(void)在技术上并不正确，尽管一些编译器可能支持它作为标准的扩展。
因此，在您的特定情况下，可以使用简短的main声明，如果符合，它将不会触发警告。
https://stackoverflow.com/questions/512222
复制相似问题