在大型 C++ 遗留应用程序中查找“死代码”
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/2380153/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Finding "dead code" in a large C++ legacy application
提问by gudnithor
I'm currently working on a large and old C++ application that has had many developers before me. There is a lot of "dead code" in the project, classes and functions that aren't used by anyone anymore.
我目前正在开发一个大型的旧 C++ 应用程序，在我之前有很多开发人员。项目、类和函数中有很多“死代码”，不再被任何人使用。
What tools are available for C++ to make a analysis of large code base to detect and refactor dead code? Note: I'm not talking about test coverage tool like gcov.
哪些工具可用于 C++ 分析大型代码库以检测和重构死代码？注意：我不是在谈论像 gcov 这样的测试覆盖率工具。
How do you find dead code in your project?
你如何在你的项目中找到死代码？
采纳答案by Alan Hymanson
You'll want to use a static analysistool
您将需要使用静态分析工具
- StackOverflow: What open source C++ static analysis tools are available?
- StackOverflow: C++ static code analysis tool on Windows
- Wikipedia: List of tools for static code analysis
- StackOverflow：有哪些开源 C++ 静态分析工具可用？
- StackOverflow：Windows 上的 C++ 静态代码分析工具
- 维基百科：静态代码分析工具列表
The main gotcha I've run into is that you have to be careful that any libraries aren't used from somewhere that you don't control/have. If you delete a function from a class that gets used by referencing a library in your project you can break something that you didn't know used the code.
我遇到的主要问题是，您必须小心不要从您无法控制/拥有的地方使用任何库。如果您从通过引用项目中的库来使用的类中删除函数，您可能会破坏一些您不知道使用了代码的东西。
回答by Alan Hymanson
回答by phw
Caolán McNamara's callcatcheris very effectively used within the LibreOffice project (~6 MLOC) to find dead code.
Caolán McNamara 的callcatcher在 LibreOffice 项目（~6 MLOC）中非常有效地用于查找死代码。
回答by Dmitry
I think your best bet would probably be a coverage tool. There're plenty for both *nix and windows. If you have unit tests, it's easy - if you have a low test coverage, then the uncovered code is either dead or not tested yet (you want both pieces of this info anyway). If you don't have unit tests, build your app with instrumentation provided by one of those tools, run it through some (should be all ideally) execution paths, and see the report. You get the same info as with unit tests, it will only require a lot more work.
我认为你最好的选择可能是一个覆盖工具。*nix 和 windows 都有很多。如果你有单元测试，这很容易——如果你的测试覆盖率很低，那么未覆盖的代码要么已经死了，要么还没有测试（无论如何你都需要这些信息）。如果您没有单元测试，请使用这些工具之一提供的检测构建您的应用程序，通过一些（应该都是理想的）执行路径运行它，然后查看报告。您获得与单元测试相同的信息，它只需要更多的工作。
Since you're using VisualStudio, I could provide you couple of links which you could consider using:
由于您使用的是 VisualStudio，我可以为您提供几个您可以考虑使用的链接：
Neither of them is free, not even cheap, but the outcome is usually worth it.
它们都不是免费的，甚至不便宜，但结果通常是值得的。
On *nix-like platforms gcovcoupled with tools like zcovor lcovis a really great choice.
回答by lilburne
Nothing beats familiarity with the code. Except perhaps rigourous pruning as one goes along.
没有什么比熟悉代码更好的了。除了随着时间的推移进行严格的修剪。
Sometimes what looks like deadwood is used as scaffolding for unit tests etc, or it appears to be alive simply because legacy unit tests exercise it, but it is never exercised outside of the tests. A short while ago I removed over 1000 LOC which was supporting external CAD model translators, we had tests invoking those external translators but those translators had been unsupported for 8+ years and there was no way that a user of the application even if they wanted to could ever invoke them.
有时看起来像枯木的东西被用作单元测试等的脚手架，或者它似乎是活着的，因为遗留单元测试运行它，但它从来没有在测试之外运行。不久前，我删除了 1000 多个支持外部 CAD 模型转换器的 LOC，我们进行了调用这些外部转换器的测试，但这些转换器已不受支持 8 年以上，即使该应用程序的用户想要可以调用它们。
Unless one is rigourous in getting rid of the dead wood, one will find your team maintaining the stuff for years.
除非有人严格清除死木，否则您会发现您的团队会维护这些东西多年。
回答by hongliang
One approach is to use "Find All References" context menu item on class and function names. If a class/function is only referenced in itself, it is almost certainly dead code.
一种方法是在类和函数名称上使用“查找所有引用”上下文菜单项。如果一个类/函数只被自身引用，它几乎肯定是死代码。
Another approach, based on the same idea, is to remove(comment out) files/functions from project and see what error messages you will get.
基于相同想法的另一种方法是从项目中删除（注释掉）文件/函数并查看您将收到哪些错误消息。
回答by Ira Baxter
See our SD C++ Test Coverage.
请参阅我们的SD C++ 测试覆盖率。
You need to do a lot of dynamic testing to exercise the code, to make sure you hit the maximum amount of coverage. Code "not covered" may or may not be dead; perhaps you simply didn't have a test case to exercise it.
您需要进行大量动态测试来练习代码，以确保达到最大覆盖量。“未涵盖”的代码可能已死，也可能未死；也许您只是没有测试用例来练习它。
回答by Schwanritter
Although not specifically for dead code, I found the Source Navigator
虽然不是专门针对死代码，但我找到了 Source Navigator
quite useful, although cumbersome to set up and a bit buggy. That was a year ago on Linux (Fedora).
非常有用，虽然设置起来很麻烦，而且有点马车。那是一年前的 Linux (Fedora)。
