c# - 处理警告的最佳实践

Question

我目前正在处理的项目每次构建时都会生成 30 多个警告。他们从项目开始就被忽略了。我猜是由于缺乏关于警告的政策。

你通常如何处理这个问题？完全忽略它们？尝试一次修复它们（这需要一些时间）？或者只是在路上一点一点地修复？

score 15 · Accepted Answer

他们中只有 30 个，只需 2 小时的工作人员就可以修复它们。

我完全不同意任何说最后期限取代修复这些警告的人。与现在解决问题相比，您将在后期代码完成阶段的问题上浪费更多的时间。忽略你的经理，他可能是一个想在老板面前看起来不错的白痴。初始质量和正确的设计比他任意的期限（在合理范围内）更重要。您首先收到警告的事实意味着有人对代码草率。仔细检查存在警告的区域是否正确。

如果您正在使用代码分析或正在编写 C/C++，那么警告有时实际上是无效的。在这种情况下，将它们编译为 (C/C++) 或 System.Diagnostics.CodeAnalysis.SuppressMessage。这可以从 VS2008 自动完成。

我没有看到任何在代码分析之外无效的 .net 警告。

score 10 · Accepted Answer

我强烈建议使用将警告视为错误的设置进行构建。当然，这将导致项目停止构建，但这是强制执行合理错误策略的唯一方法。

完成此操作后，您可以检查您收到的警告并做出一些合理的决定。可能有一些警告是良性的并且您不关心，因此将这些警告添加到要忽略的警告列表中。修复其余部分。如果您现在没有时间修复所有问题，请添加 #pragma（或 C# 等效项）以忽略每个文件中出现的特定警告，并为每个文件提交错误以确保稍后解决它们。

score 9 · Accepted Answer

在我们的开发团队中，每个人都需要在周五啤酒点之前清理他们的警告。如果您不修复警告 - 没有啤酒适合您。令人惊讶的是，这是一个很好的动力。

score 4 · Accepted Answer

大多数程序员在编写完每个结构后都会定期构建他们的代码，只是为了看看它是否正确构建。这是标记警告的时间（在 VB 中，它们也被后台构建标记）。

我将在每次构建时修复警告作为一项政策。我也不接受来自我的团队的任何标记警告的代码。只有极少数类型的警告是“可接受的”。

所以，我的策略是，我不会在以后将它们全部修复在一起，而是在它们被标记时修复它们。附带说明一下，当我的代码开始标记警告时，我会责备自己编写不符合我标准的代码。

score 4 · Accepted Answer

去年秋天，我继承了一个新的 5,000 行 Java 子系统，它有 100 个被忽略的警告。和这里的其他受访者一样，我的策略是修复每一个警告，在这样做的过程中，我发现 100 个中的三个是真正的编程错误。警告是有原因的，所以不要忽视它们，修复它们。

score 3 · Accepted Answer

每个警告都应该被修复，或者特别禁用（使用编译器指令或消除它的代码结构）。
如果您决定忽略警告而不禁用它，那么所有警告都将变得毫无意义——因为您只是不再查看它们。你知道有一些“好的”警告，那么为什么还要看这个列表呢？

另外，强烈建议在最高警告级别进行编译，并“将警告视为错误”（但这是由您的编译器完成的）。如果您的编译器不支持此设置 - 尝试通过查看其输出/返回值作为构建脚本/过程的一部分来强制执行它。

score 1 · Accepted Answer

最佳做法是将它们一起修复。您应该修复您现在拥有的那些，看起来可能需要一些时间，但它们通常是可以轻松修复的小语法错误。然后，当您在创建更多代码时开始获取它们时，您可以随时修复出现的那些。

我也总是将我的项目保持在警告级别 4，这是最高级别的警告，这样当我编译时，我可以修复默认编译器（Visual Studio）认为错误的所有内容。

score 1 · Accepted Answer

我还认为，您应该一起修复它们，在此之后我建议您切换编译器设置以将所有警告视为错误。

score 1 · Accepted Answer

在编程时，您会遇到很多问题，这些问题不会被编译时捕获（邪恶的运行时错误）。所以编译器无法找到所有问题（也就是错误）。在某些情况下，他只是说，嗯，可能有问题，但我真的不知道，请检查一下（也就是警告）。因此，请查看警告，修复它并继续。

在极少数情况下，你真的知道你在做什么，只是想，我知道这个警告，但这段代码是正确的，所以不要再打扰我了。在这些（非常罕见的）情况下，您可以封装提到的行

// Why you think this warning should be disabled at this point
#pragma warning disable xxx
/// ... some code ...
#pragma warning restore xxx

并继续，编译器不再提及。

因此，请查看所有警告并修复它们。通过重新编程或暂时禁用此警告。

PS真的不要在您的项目设置中禁用警告。因为在这种情况下，您将在全局范围内禁用它（因此可能会为将来创建的代码），也不能添加任何禁用它的注释。

score 0 · Accepted Answer

想象一下你的项目是一辆汽车。

如果任何时候您启动汽车时 30-40 个警告灯闪烁，您会怎么做？

如果您的构建脚本发出警告，您至少必须看看发生了什么，为什么会有这个警告。当然，您可以有运行带有警告的系统的示例，但这不是您想要的（我期望）。

我们使用一些静态代码分析器lime PMD 或findBugs（都用于Java）。每次构建后，我们还会修复这些工具提供的警告。

如果您的警告出于某种原因并不重要，那么请查看您的语言是否提供了诸如@supressWarning 之类的内容。其实这不是推荐。这只是一个评论。

score 0 · Accepted Answer

故意编码，割草机，好像你的警告是在跟踪纸上推出的。像蝴蝶的翅膀一样脆弱，像蚕的茧一样紧紧抓住——当你能把它的长度编码成印刷警告的长度，并且不留下任何错误的痕迹，你就会学会。——朴老师

如果您收到的警告标记了您没有考虑到的事情，您应该继续将警告视为错误，并立即修复它们。

如果你收到的警告总是关于你故意做的事情，并且生成的代码符合你的意图，并且修复它们所花费的时间不可忽略，你可以忽略它们，但你需要一个新的习惯用于修复错误。

现在进行修复的一部分必须包括检查每个错误，以查看是否有任何当前被忽略的警告实际上标记了错误。保持运行计数。只要忽略的警告没有帮助，就继续。如果/当您发现您忽略了两个有意义的警告时，请切换回将所有警告视为错误。给自己一些时间来改进，然后再试一次。

score -1 · Accepted Answer

程序员抽烟

一个人站在街角，一根接一根地抽着烟。一位路过的女士注意到他并说

“喂，你不知道那些东西会害死你吗？我的意思是，你没看到盒子上的巨大警告吗？！”</p>

“没关系”，那家伙说，随口吐了口气，“我是一名计算机程序员”</p>

“所以？有什么关系？”</p>

“我们不关心警告。我们只关心错误。”</p>

;)

我的建议是忽略，直到您的解决方案完美运行。然后开始修复警告；因为在大多数情况下，该行业是“以截止日期为导向的”。；）

score -2 · Accepted Answer

我实际上做了什么：我当前的项目也产生了 30-40 个警告，我忽略了它们。

我应该做什么：修复它们，因为其中一些可能是有意义的。

c# - 处理警告的最佳实践

13 回答 13

Related

Reference