我参与过许多项目，在这些项目中，其他人给了我要更新的代码。我经常编译它并收到大约 1,000 多个编译器警告。当我看到编译器警告时，它们让我觉得很脏，所以我的首要任务是清理代码并将它们全部删除。通常我会发现十几个问题，比如未初始化的变量。
我不明白为什么人们将它们留在里面并且没有完全干净的编译而没有警告。我错过了什么吗？有什么正当理由让他们离开吗？有什么恐怖故事可以分享吗？
KPexEA
问问题
11772 次
18 回答
91
我会清理任何警告。即使你知道是无害的（如果存在这样的事情）也会给编译代码的人留下不好的印象。
如果我不得不编写其他人的代码，这是我会寻找的“臭”标志之一。
如果不是真正的错误或潜在的未来问题，那将是马虎的迹象
于 2008-10-08T17:05:04.263 回答
48
清理它们，即使它们并不表示真正的问题。否则，如果出现表明确实存在问题的警告，您将无法通过所有噪音看到它。
于 2008-10-08T17:09:09.933 回答
38
在我的工作中，将警告视为错误的编译器设置已打开。所以，没有警告，否则它不会编译:)
于 2008-10-08T17:06:58.063 回答
20
我同意最好消除所有警告。如果您收到数以千计的警告，您应该优先考虑您的修复。
开始将编译器设置为最低警告级别。这些警告应该是最重要的。当这些都是固定的，增加你的警告级别并重复，直到你达到最高警告级别。然后设置您的编译选项，以便将警告视为错误。
如果您发现您怀疑可以安全忽略的警告，请进行一些研究以验证您的理论。只有这样才能禁用它，并且只能以尽可能最小的方式禁用。大多数编译器都有#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 )
请注意，这只会禁用单行代码的警告。使用此方法还允许您在将来对代码进行简单的文本搜索以进行更改。
或者，您通常可以为单个文件或所有文件禁用特定警告。恕我直言，这是危险的，应该只是最后的手段。
于 2008-10-08T17:25:01.680 回答
14
如果可能的话，把它们清理干净。但是，在多平台/多编译器代码库上（我曾经研究过一个在 7 个不同操作系统上使用 6 个不同编译器编译的代码库），但这并不总是可能的。我见过编译器出错的情况（Itanium 上的 HP-UX aCC，我在看着你），但这确实很少见。正如其他人指出的那样，您可以在这种情况下禁用警告。
很多时候，这个版本的编译器中的警告可能会在下一个版本中变成错误（从 gcc 3.x 升级到 4.x 的任何人都应该熟悉它），所以现在清理它。
一些编译器会发出非常有用的警告，在某些情况下会成为问题——Visual C++ 2005 和 2008 可以警告您关于 64 位问题，这在当今是一个巨大的好处。如果您有任何迁移到 64 位的计划，只需清除这些警告就会大大减少您的移植时间。
于 2008-10-08T17:41:01.723 回答
9
在某些情况下，我会在代码中留下警告，或者清理它们是不可行的（尽管我确实删除了我可以删除的警告）。例如：
- 如果您正在做某事，并且您知道它需要更多的工作/关注，请留下警告以表明这可能是适当的
- 如果您使用 /clr 编译 C++，则会出现一些关于导致生成本机代码的警告；当无法在功能上更改代码库时，抑制所有这些警告可能很麻烦
- 当您不了解修复程序的作用时清除警告。我已经用 PC-Lint 警告做了几次，最终引入了错误。如果您不知道更改的确切效果是什么（例如：C 样式强制转换以消除警告），请不要这样做。找出警告，或者不理会代码是我的建议。
无论如何，这些都是我想不到的，留下警告可能是合适的。
于 2008-10-08T18:37:33.700 回答
6
最糟糕的是，当您编写新代码时，很难知道您是否不小心引入了更多警告，因为有太多警告，您无论如何都忽略它们。
将它们全部清理干净的问题在于，您可能需要也可能不需要时间。但是，是的，通常你应该尽可能多地清理。
于 2008-10-08T17:08:02.243 回答
6
因为没有时间修复它们而在代码中留下警告就像因为早上没有足够的时间而不刷牙一样。这是代码卫生的基本问题。
于 2008-10-08T19:18:57.440 回答
5
始终清理您的警告。如果您有特定情况知道警告是可以的，则仅针对该实例禁止它。
虽然有些警告可能是良性的，但大多数都表明代码存在真正的问题。
如果您不清理所有警告，那么警告列表将继续增长，真正的问题案例将在警告噪音的海洋中消失。
于 2008-10-08T17:07:18.283 回答
4
一个真正优秀的程序员的特征之一是糟糕的代码让他们反胃。
我努力让我的所有代码不仅编译器干净，而且在我的 IDE 内部也干净，设置为相当挑剔的水平。如果我比该工具更了解，有时我需要抑制警告实例，但至少它也可以用作文档。
于 2008-10-08T17:08:01.230 回答
3
我总是启用所有警告，然后将我的项目设置为在有任何警告时停止构建。
如果有警告，那么你需要检查每一个，以确保没有问题。一遍又一遍地这样做是浪费时间。不这样做意味着将导致错误潜入您的代码。
有一些方法可以删除警告（例如#pragma argsused）。
让编译器完成工作。
于 2008-10-08T20:28:33.663 回答
2
我曾使用过许多嵌入式系统，其中的警告会导致不稳定、崩溃或内存损坏。除非您知道警告是无害的，否则应该对其进行处理。
于 2008-10-08T19:16:32.470 回答
1
警告是并且应该被视为错误。如果您的编码不够好，无法摆脱警告，那么您可能不应该编码。在我的小组中，我们决定将所有警告都强制为错误。它完全结束了这个讨论，真的，恕我直言，提高了代码质量。
于 2008-10-08T17:16:36.533 回答
0
我不喜欢警告。我尽可能地删除它们。
有时，当面临完成工作的压力时，我会留下一些。不过我很少离开他们。我觉得你很脏，如果还有的话。
于 2008-10-08T17:06:21.030 回答
0
我工作的代码库有超过 4000 个警告。其中一些是合法问题。我们从来没有时间去修复它们，也没有重构其他损坏的东西......部分原因是代码太旧了，它早于标准化的 C++。我们只能在 VC++ 6 中编译。
于 2008-10-08T17:07:46.770 回答
0
如果需要，请始终清除所有警告或明确禁止它们。编译时警告的默认设置应该尽可能高（例如 VS 上的级别 4）。
于 2008-10-08T17:18:07.263 回答
0
我的老板创建了一些我现在维护的代码。他使用编译器标志来隐藏他的贬损警告。
当我有时间时，我会尽我所能清理并清理。
于 2008-10-08T23:02:03.230 回答
0
我尝试编译具有相当高级别警告的代码并将它们全部清理掉，除了“有符号/无符号比较”警告，我确信我应该修复但永远不会被打扰。
简短版本：在 g++ 中，我使用“-Wextra -Wno-sign-compare”并删除所有消息。
于 2008-10-11T16:28:00.377 回答