我已经在许多项目中工作过，我已经被其他人更新了代码。我经常编译它，并获得大约1,000多个编译器警告。当我看到编译器警告时，他们让我觉得很肮脏，所以我的第一个任务是清理代码并将其全部删除。通常我会发现大约十几个像未初始化变量这样的问题。C/C++编译器警告：您是否清理所有代码以将其删除或将它们留在？
我不明白为什么人们把它们放在里面，没有完全干净的编译没有警告。我错过了什么吗？有没有任何理由让他们离开？任何恐怖故事分享？
我不喜欢的警告标志。我尽可能地删除它们。
有时，在完成工作的压力下，我留下了一些。尽管我很少离开他们。我觉得和你一样，如果还有剩下的话就肮脏。
在我的工作中，打开了将警告视为错误的编译器设置。所以，没有警告，或者它不会编译:)
总是清理你的警告。如果你有一个特定的情况，你知道这个警告是可以的，那么只有在这种情况下才能禁止它。
虽然一些警告可能是良性的，但最代表的是代码的真正问题。
如果您没有清理所有警告，那么警告列表将继续增长，真正的问题案例将在警告噪音的海洋中丢失。
我工作的代码库有超过4000条警告。其中一些是合法问题。我们从来没有时间进入并修复它们，也没有重构其他破碎的东西......部分原因是，这是因为代码太早了，它早于标准化的C++。我们只能在VC++ 6.0中编译。
一个非常好的程序员的特点之一就是糟糕的代码给了他们一个不稳定的胃。
我努力让我的所有代码不仅仅是编译器干净，而且在我的IDE里面设置为相当挑剔的级别。如果我知道比这个工具更好，我有时需要禁止一个警告实例，但至少也可以作为文档。
最糟糕的部分是，当你写新代码时，很难知道你是否意外地引入了更多的警告，因为有太多你无视它们而忽略它们。
将它们全部清理的问题是，您可能需要时间或可能没有。但是，一般来说，你应该尽可能地清理。
清理他们，即使他们没有指出真正的问题。否则，如果出现表明存在真正问题的警告，则不会通过所有噪声看到它。
警告是，应该被视为错误。如果你不能很好地编码以摆脱你的警告，那么你可能不应该编码。在我的小组中，我们决定强制所有警告发生错误。它完全结束了这个讨论，真的，恕我直言，提高代码质量。
请务必清理所有警告或在需要时明确禁止它们。 编译时，警告的默认设置应该是最高可能的（例如VS上的级别4）。
我同意最好消除所有警告。如果您收到成千上万的警告，您应该优先考虑您的修补程序。
开始将您的编译器设置为最低警告级别。这些警告应该是最重要的。当这些问题得到解决时，增加警戒级别并重复，直到达到最高警戒级别。然后设置您的编译选项，以便将警告视为错误。
如果你发现你怀疑是安全的忽视警告，做一些研究，以验证你的理论。只有这样，才能以最小的方式禁用它。大多数编译器有#pragma指令，可以禁用/启用仅用于文件的一部分的警告。这里是一个Visual C++的例子：
typedef struct _X * X; // from external header, not 64-bit portable
#pragma warning(push)
#pragma warning(disable: 4312) // 64-bit portability warning
X x = reinterpret_cast<X>(0xDDDDDDDD); // we know X not 64-bit portable
#pragma warning(pop)
请注意，这只能禁用单行代码的警告。使用这种方法还可以让您在未来对代码进行简单的文本搜索以进行更改。
另外，您可以通常是单个文件或所有文件禁用特定的警告。恕我直言，这是危险的，应该只是最后的手段。
清理它们如果可能的话。在一个多平台/多编译器的代码库上（我已经编写了一个在6个不同编译器上编译的7个不同的操作系统），但这并不总是可能的。我见过编译器只是错误（Itanium上的HP-UX aCC，我在看你）的情况，但这种情况很少见。正如其他人所指出的，您可以在这种情况下禁用警告。
很多时候，什么是在这个版本的编译器的警告可能会成为下一个版本（任何人GCC 3.x升级到4.x的应该是熟悉）的错误，所以现在清理。
一些编译器会发出非常有用的警告，这将成为在某些情况下的问题 - VISUAL C++ 2005和2008可警告你，约64位的问题，这是一个巨大的好处现在。如果您有任何计划迁移到64位，只是清理这些警告将显着减少您的端口时间。
有一些情况下，我会留在代码中的警告，或者是不可行他们清理（虽然我取出我可以的）。例如：
无论如何，这些都是我的头顶的情况下留下警告可能是适当的。
我曾与许多嵌入式系统的工作，在那里警告会导致不稳定，崩溃或内存损坏。除非你知道警告是无害的，否则应该处理。
留在你的代码中的警告，因为你没有足够的时间来解决这些问题是不一样刷牙，因为你没有在早上足够的时间。这是代码卫生的基本问题。
我始终启用所有警告，然后将我的项目停止建设，如果有任何警告。
如果有警告，那么你需要检查每一个，以确保没有问题。反复做这是浪费时间。不这样做意味着会导致错误蔓延到您的代码中。
有多种方法可以删除警告（例如#pragma argsused）。
让编译器完成这项工作。
我的老板创建了一些我现在维护的代码。他使用编译器标志来隐藏他的解除警告。
当我有空的时候，我会经历并清理我所能做的。
我尝试编译代码具有相当高的水平的警告和清理它们加起来，除了“无/有符号的比较”的警告，这点我敢肯定，我应该可以解决，但不能被人打扰。
短版：在G ++我用 “-Wextra -Wno-sign-compare的” 和摆脱所有消息。
也许一个更好的问题是“你是否修复了警告，或者把它们去掉？” – ilitirit 2008-10-08 21:58:30
作为一个方面说明，我强烈建议阅读由Demeyer等编写的有价值的书籍** Object-Oriented Reengineering Patterns **。人。 （[免费电子图书]（http://scg.unibe.ch/download/oorp/））。他建议优先考虑变更并首先以迭代增量的方式处理最有价值的变更。因此，答案取决于我认为的项目时间框和优先事项。 – 2013-04-24 09:04:40
另外，对于gcc，您应该始终运行至少`-Wall`。我更喜欢`-Wextra`，有时候``pedantic`甚至会有所帮助。 – 2013-07-08 05:06:36