我目前正在开发的项目每次构建时都会生成30多个警告。从项目开始就忽略了它们。我想由于缺乏关于警告的政策。
你通常如何处理这个？完全忽略它们？尝试一次修复它们（这需要一些时间）？或者一路上一点一点地修复？
答案 0 :(得分：12)
其中只有30个是2小时的工作人员只是修理它们。
我完全不同意那些说截止日期取代修正这些警告的人。与现在修复问题相比，您将在后期代码完成阶段浪费更多时间来解决问题。忽略你的经理他可能是一个想要对老板好看的白痴。初始质量和正确的设计比他的任意期限（在合理范围内）更重要。事实上，你首先有警告意味着某人对代码很邋。。仔细检查存在警告的区域是否正确。
如果您正在使用代码分析或正在编写C / C ++，那么警告有时真的无效。在那种情况下，编译它们（C / C ++）或System.Diagnostics.CodeAnalysis.SuppressMessage。这可以从VS2008自动完成。
我没有看到任何在代码分析之外无效的.net警告。
答案 1 :(得分：9)
我强烈建议使用设置将警告视为错误。当然，这会导致项目停止构建，但这是实施合理错误策略的唯一方法。
完成后，您可以检查自己的警告并做出一些合理的决定。可能有些警告是良性的，您不关心，因此请将这些警告添加到要忽略的警告列表中。修复其余部分。如果您现在没有时间修复它们，请添加#pragma（或C＃equiv）以忽略每个文件中发生的特定警告，并为每个文件提交一个错误，以确保稍后解决。
答案 2 :(得分：8)
在我们的开发团队中，每个人都需要在星期五的啤酒时间之前清理他们的警告。如果你不修理你的警告 - 没有啤酒给你。令人惊讶的是，这是一个很好的激励因素。
答案 3 :(得分：4)
去年秋天，我继承了一个新的5,000行Java子系统，它有100个被忽略的警告。像其他受访者一样，我的政策是修复每一个警告，在这样做的过程中，我发现100个中的三个是真正的编程错误。警告是有原因的，所以不要忽略它们，修复它们。
答案 4 :(得分：3)
大多数程序员在编写每个构造之后定期构建代码，只是为了查看它是否正确构建。这是警告被标记的时间（在VB中，它们也被后台构建标记）。
我制定了一项政策来修复每个版本的警告。我也不接受我的团队中标记警告的任何代码。只有极少数类型的警告是“可接受的”。
所以，我的政策是，不是在以后将它们全部固定在一起，而是在它们被标记时修复它们。作为旁注，当我的代码开始标记警告时，我责备自己编写不符合我标准的代码。
答案 5 :(得分：3)
应该修复或特别禁用每个警告（使用编译器指令或消除它的代码构造） 如果您决定在不禁用警告的情况下忽略警告，则所有警告都会变得毫无意义 - 因为您只是不再查看它们了。你知道有一些“好的”警告，所以为什么还要费心查看清单呢？
另外，强烈建议在最高警告级别进行编译，并将“警告视为错误”（但这是由编译器完成的）。如果您的编译器不支持此设置 - 请尝试通过查看其输出/返回值作为构建脚本/进程的一部分来强制执行它。
答案 6 :(得分：1)
最佳做法是将它们全部修复在一起。你应该修复你现在拥有的那些，看起来它可能需要一些时间，但它们通常很少有语法错误，可以轻松修复。然后，当您在创建更多代码时开始获取它们时，您可以修复随后出现的代码。
我也始终将我的项目保持在警告级别4，这是最高级别的警告，因此当我编译时，我可以修复默认编译器（视觉工作室）认为错误的所有内容。
答案 7 :(得分：1)
我也认为，您应该将它们全部修复在一起，之后我建议您切换编译器设置以将所有警告视为错误。
答案 8 :(得分：1)
编程时你会遇到很多问题，这些问题不会被编译时捕获（邪恶的运行时错误）。因此编译器无法找到所有问题（也就是错误）。在某些情况下，他只是说，嗯，可能有问题，但我真的不知道，请检查它（也就是警告）。因此，请查看警告，修复并继续。
在极少数情况下，你真的知道你做了什么，只是想想，我知道这个警告，但这段代码是正确的，所以不要再打扰我了。在这些（非常罕见的）情况下，您可以封装用
提到的行// Why you think this warning should be disabled at this point
#pragma warning disable xxx
/// ... some code ...
#pragma warning restore xxx
然后继续，编译器不再提及了。
因此，请查看所有警告并修复它们。通过重新编程或临时禁用此警告。
P.S。确实不在项目设置中禁用警告。在这种情况下，您可以全局禁用它（也可能是将来创建的代码），也不能添加任何注释，以禁用它。
答案 9 :(得分：0)
程序员吸烟
一个人站在街角一个接一个地抽着烟。一位女士走过去告诉他并说道
“嘿，难道你不知道那些事可以杀了你吗？我的意思是，你没看到盒子上的巨大警告吗？！““没关系”这个家伙说，随便抽一声“我是电脑程序员”
“所以？什么与任何事情有关？“
“我们不关心警告。我们只关心错误。“
）
在您使解决方案完美运行之前，我的建议是无效的。然后转到修复警告;因为在大多数情况下，该行业是“截止日期”。;）
答案 10 :(得分：0)
想象一下你的项目是一辆汽车。
如果你开车的时候你会怎么做30-40个警示灯闪烁？
如果您的构建脚本发出警告，必须至少看看发生了什么，为什么会出现此警告。当然，您可以使用带警告的系统运行示例，但这不是您想要的（我希望）。
我们使用一些静态代码分析器lime PMD或findBugs（两者都用于Java）。在每次构建之后，我们还会修复这些工具提供的警告。
如果您的警告因任何原因而不重要，那么请查看您的语言是否提供@supressWarning等内容。实际上这不是推荐。这只是一个评论。
答案 11 :(得分：0)
有意识的代码，草moker，好像你的警告是在路径纸上推出的。 像蝴蝶的翅膀一样脆弱，紧贴着蚕茧的茧 - 当你可以编码相当于印刷警告的长度，并且不留下任何错误的痕迹时，你就会得到学习。 --Master Poh
如果你收到的警告标记了你没有考虑到的事情， 你应该继续将警告视为错误，并立即修复它们。
如果你得到的警告总是关于你故意做的事情，并且生成的代码符合你的意图，修复它们的时间不可忽略，你可以忽略它们，但你需要修复错误的新仪式。
进行修复的部分现在必须包括检查每个错误，以查看是否有任何当前被忽略的警告实际标记了错误。保持运行计数。只要被忽略的警告没有帮助，继续。如果/当您发现您忽略了两个有意义的警告时，请切换回将所有警告视为错误。给自己一些时间来改进，然后再试一次。
答案 12 :(得分：-1)
我实际做了什么：我当前的项目还会产生30-40个警告，我会忽略它们。
我应该做些什么：修复它们，因为它们中的一些可能是有意义的。