我们的项目经理最近设置了一个策略，要求开发人员删除所有编译器警告。我理解一些警告确实很容易被删除，有些警告并不那么容易。因此，一些开发人员使用各种可能的方式来实现目标。例如，使用显式强制转换将double转换为float，浮动到int，签名到unsigned等等。由于我们的代码库是如此之大，超过20年的30-50开发人员的工作，我真的怀疑这个努力多少如果确实有一些优点，可以真正帮助我们。任何人都可以提出一些建议或论点吗？我们的项目使用C ++。
答案 0 :(得分：13)
一旦你让编译器警告失效，“真正的”警告也会被忽略。我无法计算出一个带有大量警告的项目的次数，只需要一点点小心，就会被删除，还有一堆非常微妙的错误。意外分配，如果，意外跌落在开关中或没有违约，意外;在for循环的结尾，无意的类型转换等警告是有原因的 - 使用它们。是的，有些是非常悬垂的，但是稍后的工作可以在以后节省很多麻烦。
清洁警告并保持清洁。你会写出更好的代码。
答案 1 :(得分：4)
在大型项目中修复所有警告可能非常棘手。有些编译器有一种相当模糊的“正确警告”的感觉。
修复警告绝对是件好事。但它应该以正确的方式完成 - 有时，正确的做法是简单地禁用该警告。
一些非常令人烦恼的是“未使用的参数” - 好吧，如果接口确定使用两个参数调用此函数，但是您只使用一个（或者没有），因为这个特定实现的作用是不使用这些参数，然后很难修复警告[你当然可以删除变量的名称（或把它作为注释）]。
同样地，有时候编译器会如此挑剔以至于不可能是正确的 - 我曾经遇到过这样的情况：函数底部没有返回“并非所有路径都返回”并且当我添加一个返回时在功能的底部，它说“无法访问的代码” - 好吧，你想要它怎么样？这是（对于那段代码）禁用相关警告的地方是正确的做法。
如果你必须使用多个编译器编译代码会变得更糟 - 有时候编译器中的“好”会变成另一个编译器中的警告，并且该警告的修复会在下一个编译器中变成警告，这可能很难解决。
一旦您制定了处理警告的策略，并删除了要删除的警告，禁用了要禁用的警告，我建议您使用“胎面警告错误”构建产品。
大多数情况下，警告对程序员来说是“好的”，不应该被忽略。但有时候“我知道我在做什么，闭嘴编译器！”是正确的方法 - 当然，大多数情况下，通过应用演员或其他一些方法来解决这些问题 - 这应该在解决问题的正确方法时完成。
答案 2 :(得分：3)
否。并非所有警告，也不是任何手段。
并非所有警告：某些编译器已经实施了风格或不准确的警告，通常会更好地取消这些警告，因为它们会分散实际问题。
绝不是：警告被编译器用来发出可疑的信号，最有趣的警告表示可能存在未定义的行为。目标不应该是删除警告只是为了安抚编译器，它应该是确保行为是明确定义的，如果不是为了使其定义良好。
我的建议是首先检查一组激活的警告，并修剪无用的警告。然后，了解警告留下的内容，并就处理每个警告的最佳方式达成一致（以获得定义的行为为目标）。最后，您将能够开始使用代码库。