研究C ++警告的后果

Question

我刚刚开始从事一项有很旧代码的工作，编译这段代码甚至启用了基本警告，产生了成千上万的警告，其中许多对我来说真的很可怕。这些代码大部分是在80年代编写的，因此管理层不会兴奋地让一些新工程师尝试修复它。

我的意见是，摆脱这些警告应该是一个高优先级，但我没有任何数据支持我。我理解管理层的想法，即修复所有警告是一项严肃的任务，并且可能不值得花费在看似按原样运行的代码上。我正在寻找一个指向错误/警告或其他类似问题的研究，所以我可以去找他们说：“我们有200,000个警告，而且从研究X开始，可能会有2000个漏洞隐藏在那里。 “

这里非常类似的讨论：https://softwareengineering.stackexchange.com/questions/111616/handling-false-positives-and-legacy-code-warnings-in-static-analysis-of-c-code

我不认为这应该因为偏离主题而被关闭，因为它是：“编程专业独有的实用，可回答的问题。”

由于偏离主题而关闭，但我找到了一项研究：http://institute.lanl.gov/isti/irhpit/presentations/ensuring-sq.pdf http://collaboration.csc.ncsu.edu/laurie/Papers/TSE-0197-0705-2.pdf

Answer 1

我认为没有这样的研究。我也打算在这里说出管理是正确的 - 试图解决所有这些警告，只是为了解决所有这些警告，这是一个坏主意。

你会通过修复警告来破坏事情！现在这个代码可能有很多错误，但是它有很多权利，并且对于你来说并且在“工作”代码中导致问题并不会很好。

在你的鞋子里，我会开始研究我需要做的任何修改/修复。在此过程中，为您触摸的所有内容编写单元测试，并清除您触摸的所有内容的警告。

我不知道您的构建系统是什么，但是如果可能的话，构建您触摸警告的所有内容，为旧内容留下警告，并将您更改的代码移动到新的“干净编译”文件中。

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

更新： 我把它作为评论开始，但我认为它应该成为答案的一部分。

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

清洁代码是我们使用的工具，以使我们的产品更好，我们的生活（以及跟随我们的脚步的人的生活）更容易。它是一个很好的工具，不过，它是一个很棒的工具，但它只是一个工具。

如果你忽略了实际的目标（制作有效的软件），你可能会陷入与你的过程相关的琐事中。这可能感觉很好，但通常不能满足用户或按时发货。

Answer 2

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

1. 该产品的开发模式是什么？它是不时的错误修正，还是不断开发新功能。
2. 是否有足够的测试覆盖率？承担重大改写，因为如果你没有像样的回归套件那就是自杀。即使这样，一些错误仍然会漏掉，但它总比没有好。
3. 是否需要更新工具链/平台？这很重要，因为许多警告实际上是不会出现任何问题的事情，只要你坚持相同的环境，你确信这个“有问题”的行为是可预测的（并且可能对你的代码是正确的）。如果你想要彻底改变其中一个，那么花时间去解决所有这些警告可能是个好主意。

警告 - ＆gt;错误在很大程度上取决于您的实际产品。

Answer 3

警告并不意味着缺陷。每个未经过彻底测试的产品都包含缺陷。如果产品经过充分测试，则没有缺陷。

很多警告因其他原因而不好。警告隐藏了维护中的新警告（可能表示新出现的缺陷）。因此，使用大量警告来维护代码会更加昂贵。

应该小心修复警告，有时甚至是内存泄漏等真正的缺陷。它永远不应该机械地完成。这很可能会打破工作产品。我在实践中已经看过几十次了。

Answer 4

可悲的事实是，修复旧代码往往是徒劳无功的冒险。旧代码通常没有单元测试，编写代码的人很久就离开了公司。如果你在代码中看到一些奇怪的东西，它可能是出于特殊原因而做的，但是从那以后很多因素都发生了变化，很难进行任何影响分析。重写旧代码时可能出现的问题太多了。相反，您应该关注的是以良好的方式编写 new 代码。

另一个问题是管理层完全不理解为什么代码应该被重写，因为代码是功能性的 - 期间