C/C++编译器警告:是清理所有代码以删除它们，还是将它们保留在中

我会清除任何警告。即使是那些你知道是无害的（如果存在这样的事情），也会给编译代码的人留下不好的印象。

如果我必须处理其他人的代码，这是我会寻找的"气味"标志之一。

如果不是真正的错误或潜在的未来问题，这将是草率的标志

清理它们，即使它们不表明是真正的问题。否则，如果出现确实表示存在真正问题的警告，您将无法通过所有噪音看到它。

在我的工作中，将警告视为错误的编译器设置是打开的。因此，没有警告，否则它不会编译：）

我同意最好消除所有警告。如果你收到成千上万的警告，你应该优先考虑你的修复。

开始将编译器设置为最低警告级别。这些警告应该是最重要的。当这些问题得到解决后，增加警告级别并重复，直到达到最高警告级别。然后设置编译选项，以便将警告视为错误。

如果你发现一个你怀疑可以安全忽略的警告，那就做一些研究来验证你的理论。只有这样才能禁用它，而且只能以最简单的方式禁用。大多数编译器都有#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 )

请注意，这只会禁用单行代码的警告。使用此方法还可以在将来对代码进行简单的文本搜索以进行更改。

或者，您通常可以对单个文件或所有文件禁用特定警告。IMHO，这是危险的，应该只是最后的手段。

如果可能的话，请清理。在多平台/多编译器的代码库上（我曾用6个不同的编译器在7个不同的操作系统上编译过一个代码库），这并不总是可能的。我见过编译器只是错误的情况（我在看安腾上的HP-UX aCC），但这是公认的罕见情况。正如其他人所指出的，在这种情况下，您可以禁用警告。

很多时候，这个版本的编译器中的警告可能会在下一个版本中变成错误（任何从gcc3.x升级到4.x的人都应该熟悉这一点），所以现在就清理它。

有些编译器会发出非常有用的警告，这些警告在某些情况下会变成问题——Visual C++2005和2008可以警告您64位问题，这在当今是一个巨大的好处。如果您有任何迁移到64位的计划，只需清除这些类型的警告就会大大减少您的端口时间。

在某些情况下，我会在代码中留下警告，或者清理它们是不可行的（尽管我确实删除了我可以删除的警告）。例如：

• 如果你正在做一些事情，并且你知道它需要更多的工作/关注，那么留下一个警告来表明这是合适的
• 如果您使用/clr编译C++，则会出现一些关于导致生成本机代码的警告；当代码库无法在功能上更改时，抑制所有这些警告可能会很麻烦
• 当您不了解修复程序的作用时，清除警告。我已经在PC Lint警告中做过几次了，但最终还是引入了错误。如果你不知道更改的确切效果是什么（例如：C风格的强制转换以消除警告），不要这样做。我的建议是找出警告，或者不要理会代码

不管怎样，这些都是我脑海中留下警告可能合适的例子。

最糟糕的是，当你编写新代码时，很难知道你是否意外地引入了更多的警告，因为警告太多了，你无论如何都会忽略它们。

把它们都清理干净的问题是，这需要时间，你可能有，也可能没有。但是，是的，一般来说，你应该尽可能多地清理。

因为没有时间修复而在代码中留下警告，就像因为早上没有足够的时间而不刷牙一样。这是代码卫生的一个基本问题。

始终清除警告。如果您有一个特定的情况，您知道警告是可以的，那么只针对该实例取消显示它。

虽然有些警告可能是善意的，但大多数警告表示代码存在真正的问题。

如果你不清理所有警告，那么警告列表将继续增加，真正的问题案例将在警告噪音的海洋中消失。

一个真正优秀的程序员的特点之一是糟糕的代码会让他们感到恶心。

我努力让我的所有代码不仅编译器干净，而且IDE内部也干净，达到一个相当挑剔的水平。如果我比该工具更了解的话，有时我需要取消显示警告实例，但至少这也可以作为文档使用。

我总是启用所有警告，然后如果有任何警告，则将我的项目设置为停止构建。

如果有警告，那么您需要检查每个警告以确保没有问题。一遍又一遍地做这件事是浪费时间。不这样做意味着将导致错误悄悄进入您的代码。

有几种方法可以删除警告（例如#pragma argsused）。

让编译器来做这项工作。

我曾处理过许多嵌入式系统，这些系统的警告会导致不稳定、崩溃或内存损坏。除非你知道这个警告是无害的，否则它应该被处理。

警告是并且应该被视为错误。如果你不能很好地编码以消除警告，那么你可能不应该编码。在我的小组中，我们决定强制所有错误警告。它完全结束了这个讨论，实际上，IMHO提高了代码质量。

我不喜欢警告。我尽可能地把它们去掉
有时，在完成工作的压力下，我会离开他们中的一些人。不过我很少离开他们。我觉得自己像你，如果还剩下的话就很脏。

我工作的代码库有4000多个警告。其中一些是合法的问题。我们从来没有时间去修复它们，也没有时间重构其他损坏的东西。。。这在一定程度上是因为代码太旧了，早于标准化C++。我们只能用VC++6进行编译。

如果需要，请始终清除所有警告或明确抑制它们。编译时，警告的默认设置应尽可能高（例如VS上的级别4）。

我的老板创建了一些我现在维护的代码。他使用编译器标志来隐藏他的降级警告。

当我有时间的时候，我会尽我所能去清理。

我试图编译具有相当高级别警告的代码，并将它们全部清除，除了"已签名/未签名比较"警告，我确信我应该修复这些警告，但永远不会被打扰。

简短版本：在g++中，我使用"-Wextra-Wno符号比较"并删除所有消息。