我们的项目经理最近制定了一项政策，要求开发人员删除所有编译器警告。我知道有些警告确实很容易删除，有些则不那么容易。因此，一些开发人员使用各种可能的方式来实现目标。例如，使用显式强制转换将 double 转换为 float、float 转换为 int、signed 转换为 unsigned 等等。由于我们的代码库如此之大，20 多年 30-50 开发人员的工作，我真的怀疑这有多少努力真的可以帮助我们，如果它确实有一些优点。谁能给你一些建议或论点？我们的项目使用 C++。
问问题
303 次
3 回答
13
一旦你让编译器警告溜走，“真正的”警告也会被忽略。我数不清有多少次我进入一个带有大量警告的项目，只要稍加小心，就会连同一堆非常微妙的错误一起被删除。if 中的意外分配，switch 中的意外跌落或没有默认值，意外；在 for 循环结束时，无意的类型转换等。警告的存在是有原因的 - 使用它们。是的，有些是非常悬疑的，但只需一点点工作就可以省去很多麻烦。
清洁警告并保持清洁。你会写出更好的代码。
于 2013-01-25T15:47:01.487 回答
4
修复大型项目中的所有警告可能非常棘手。并且一些编译器对“需要警告的正确事情”有相当模糊的感觉。
修复警告绝对是一件好事。但它应该以正确的方式完成 - 有时，正确的做法是简单地禁用该警告。
一些真正令人讨厌的是“未使用的参数” - 好吧，如果接口确定使用两个参数调用此函数，但您只使用一个（或没有），因为这个特定实现所做的不是使用这些参数，那么它就是很难修复警告[您当然可以删除变量的名称（或将其作为注释）]。
同样，有时编译器可能非常挑剔，以至于不可能是正确的——我遇到过这样的情况：函数底部没有返回会给出“并非所有路径都导致返回”，而当我在底部添加返回时该功能，它说“无法访问的代码” - 好吧，你想要它？这是（对于该部分代码）禁用相关警告的正确做法。
如果您必须使用多个编译器编译代码，情况会变得更糟 - 有时编译器中的“好”在另一个编译器中变成警告，并且该警告的修复在下一个编译器中变成警告，这可以很难解决。
一旦您制定了应对警告的策略，并删除了您想要删除的那些，禁用了您想要禁用的那些，我建议您使用“将警告视为错误”来构建您的产品。
大多数时候，警告对程序员来说是“好”的，不应该被忽视。但有时“我知道我在做什么，编译器闭嘴！” 是正确的方法——当然，大多数时候，这些都是通过应用演员或类似的方法来解决的——当它是解决问题的正确方法时应该这样做。
于 2013-01-25T16:04:34.810 回答
3
不，不是所有的警告，也不是任何手段。
并非所有警告：一些编译器已经实现了风格或不准确的警告，通常最好停用这些警告，因为它们会分散实际问题的注意力。
无论如何都不是：编译器使用警告来表示可疑的事情，例如，最有趣的警告表示可能的未定义行为。目标不应该只是为了安抚编译器而删除警告，而应该是确保行为是明确定义的，如果不是使其明确定义。
我的建议是首先查看已激活的警告集，并删除无用的警告。然后，了解留下的警告是关于什么的，并就处理每个警告的最佳方式达成一致（目标是获得明确的行为）。最后，您将能够开始使用您的代码库。
于 2013-01-25T15:48:38.033 回答