我刚开始从事一份代码非常旧的工作，编译这段代码时即使启用了基本警告也会产生数千个警告，其中许多对我来说真的很可怕。大部分代码是在 80 年代编写的，因此管理层对于让一些新工程师尝试修复它并不感到兴奋。
我的观点是消除这些警告应该是当务之急，但我没有任何数据可以支持我。我理解管理层的想法，即修复所有警告是一项严肃的工作，并且可能不值得为看起来可以正常工作的代码付出努力。我正在寻找一项指向错误/警告或类似内容的研究，因此我可以去找他们并说：“我们有 200,000 个警告，从研究 X 中，很可能有 2,000 个错误隐藏在其中。 "
我认为这不应该因为跑题而被关闭，因为它是一个：“编程行业独有的实用、可回答的问题”。
由于题外话而关闭，但我发现了一项研究： http: //institute.lanl.gov/isti/irhpit/presentations/ensuring-sq.pdf http://collaboration.csc.ncsu.edu/laurie/论文/TSE-0197-0705-2.pdf
我认为没有这样的研究。我也将在这里冒昧地说管理层是正确的——试图修复所有这些警告，只是修复所有这些警告，是一个坏主意。
您将通过修复警告来破坏事情！现在该代码可能有很多错误，但它有很多正确之处，并且对于您来说，在“工作”代码中出现问题并不会很好地解决。
在您的情况下，我将着手进行我需要做的任何修改/修复。在此过程中，为您接触的所有内容编写单元测试，并为您接触的所有内容清除警告。
我不知道你的构建系统是什么，但如果可能的话，构建你接触到的所有东西，并打开警告，为旧的东西留下警告，并将你更改的代码移动到新的“干净编译”文件中。
你不会很快掌握它，但你不能只是跳进去改变一堆东西。你必须找到一种工作方式，让你在不破坏最终用户的情况下取得进步。
更新：我将此作为评论开始，但我认为它应该成为答案的一部分。
干净的代码（没有警告的代码、具有单元测试的代码、易于理解的代码）不是也不应该成为任何实际必须在现实世界中完成任务的开发人员的目标。
干净的代码是我们使用的一种工具，它可以让我们的产品变得更好，让我们的生活（以及那些追随我们脚步的人的生活）更轻松。这是一个很好的工具，不，一个很棒的工具，但它只是一个工具。
如果您忽略了实际目标（生产有效的软件），您可能会陷入与您的流程相关的琐事中。这可能感觉很好，但它通常不能满足用户，或按时交付产品。
我同意 Michael Khone 所说的大部分内容，但这里涉及到相当多的产品/开发管理，评估取决于此。您应该问自己一些（但不是全部）主要问题：
所以警告 -> 错误很大程度上取决于您的实际产品。
警告并不意味着缺陷。每一个没有经过充分测试的产品都包含缺陷。如果产品经过良好测试，则没有缺陷。
由于其他原因，许多警告都是不好的。警告隐藏了新的警告（可能表明新出现的缺陷）以防止维护。因此，维护带有大量警告的代码会更加昂贵。
修复警告，有时甚至是内存泄漏等真正的缺陷都应该小心。它永远不应该机械地完成。这很可能会破坏工作产品。我在实践中见过几十次。
可悲的事实是，修复旧代码往往是徒劳的冒险。旧代码通常没有单元测试，编写代码的人早已离开公司。如果您在代码中看到一些奇怪的东西，它可能是出于特定原因而完成的，但是从那时起许多因素发生了变化，以至于很难进行任何影响分析。重写旧代码时有太多事情可能出错。相反，您应该专注于以良好的风格编写新代码。
另一个问题是管理层完全不理解为什么要重写代码，因为代码就是功能——时期