C++警告的后果研究

我认为没有任何这样的研究。我也要冒险说，管理层是正确的——试图修复所有这些警告，仅仅修复所有这些警报，是个坏主意。

你会通过修正警告来破坏一切！现在，这个代码可能有很多错误，但也有很多正确的地方，对于你来说，在"工作"代码中经历并造成问题是不会顺利进行的。

站在你的立场上，我会着手做我需要做的任何修改/修复。在这个过程中，为你接触的每一件事编写单元测试，并清除你接触的所有事情的警告。

我不知道你的构建系统是什么，但如果可能的话，构建你接触到的所有带有警告的东西，对旧的东西关闭警告，并将你更改的代码移动到新的"干净编译"文件中。

你不会很快掌握它，但你不能只是跳进去改变一堆东西。你必须找到一种工作方式，让你在不破坏最终用户利益的情况下取得进展。

更新：我一开始只是一个评论，但我认为这应该成为答案的一部分。

干净的代码（没有警告的代码、有单元测试的代码、易于理解的代码）不是，也不应该成为任何在现实世界中必须完成任务的开发人员的目标。

清洁代码是我们用来让我们的产品更好，让我们的生活（以及那些追随我们脚步的人的生活）更轻松的工具。这是一个好工具，不，一个伟大的工具，但它只是一个工具。

如果你忽视了实际目标（生产出有效的软件），你可能会陷入与过程相关的琐事中。这可能感觉不错，但通常不会让用户满意，也不会按时发货。

警告并不意味着缺陷。每一个没有经过充分测试的产品都有缺陷。若产品经过良好的测试，那个么就并没有缺陷。

由于其他原因，很多警告都很糟糕。这些警告隐藏了来自维护的新警告（可能表示新产生的缺陷）。因此，维护带有大量警告的代码的成本更高。

修复警告，有时甚至是真正的缺陷，如内存泄漏，都应该小心。绝不能机械地完成。这很可能会破坏正在运行的产品。我已经在实践中见过几十次了。

我同意Michael Khone的大部分说法，但这里涉及到相当多的产品/开发管理，评估取决于此。你应该问自己的一些（但不是全部）主要问题：

1. 这个产品的开发模式是什么？它只是不时地进行一些小的增强的错误修复，还是你不断地在上面开发新功能
2. 是否有足够的测试覆盖率？如果你没有一个像样的回归套件，像这样进行重大重写就是自杀。即便如此，仍然会有一些错误出现，但总比什么都没有要好得多
3. 是否需要更新工具链/平台？这一点很重要，因为许多警告实际上都是不会显示任何问题的，只要你坚持在同一个环境中，你确信这种"有问题"的行为是可预测的（并且可能对你的代码是正确的）。然而，如果你想彻底改变其中一个，那么花时间解决所有这些警告可能是一个非常好的主意

所以警告->错误在很大程度上取决于您的实际产品。

可悲的事实是，修复旧代码往往是徒劳的冒险。旧代码通常没有单元测试，编写代码的人早已离开公司。如果你在代码中看到一些奇怪的事情，可能是出于特定的原因，但从那时起，很多因素都发生了变化，很难进行任何影响分析。重写旧代码时可能会出现太多错误。相反，您应该关注的是以良好的风格编写新的代码。

另一个问题是，管理层完全不理解为什么要重写代码，对他们来说，代码就是功能性的——周期