C# 查找未使用的代码

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/245963/
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

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-08-03 19:41:14  来源:igfitidea点击:

Find unused code

c#.netrefactoring

提问by Andre

I have to refactor a large C# application, and I found a lot of functions that are never used. How can I check for unused code, so I can remove all the unused functions?

我要重构一个大型的 C# 应用程序,我发现了很多从未使用过的函数。如何检查未使用的代码,以便删除所有未使用的函数?

采纳答案by Jarrett Meyer

Yes, ReSharper does this. Right click on your solution and selection "Find Code Issues". One of the results is "Unused Symbols". This will show you classes, methods, etc., that aren't used.

是的,ReSharper 就是这样做的。右键单击您的解决方案并选择“查找代码问题”。结果之一是“未使用的符号”。这将向您显示未使用的类、方法等。

回答by Mitch Wheat

ReSharperdoes a great job of finding unused code.

ReSharper在查找未使用的代码方面做得很好。

In the VS IDE, you can right click on the definition and choose 'Find All References', although this only works at the solution level.

在 VS IDE 中,您可以右键单击定义并选择“查找所有引用”,尽管这仅适用于解决方案级别。

回答by Jeff Schumacher

It's a great question, but be warned that you're treading in dangerous waters here. When you're deleting code you will have to make sure you're compiling and testing often.

这是一个很好的问题,但请注意,您在这里涉足危险的水域。当您删除代码时,您必须确保经常编译和测试。

One great tool come to mind:

想到了一个很棒的工具:

NDepend - this tool is just amazing. It takes a little while to grok, and after the first 10 minutes I think most developers just say "Screw it!" and delete the app. Once you get a good feel for NDepend, it gives you amazing insight to how your apps are coupled. Check it out: http://www.ndepend.com/. Most importantly, this tool will allow you to view methods which do not have any direct callers. It will also show you the inverse, a complete call tree for any method in the assembly (or even between assemblies).

NDepend - 这个工具真是太棒了。需要一点时间才能理解,在前 10 分钟之后,我认为大多数开发人员只会说“去吧!” 并删除该应用程序。一旦您对 NDepend 有了良好的感觉,它就会让您对应用程序的耦合方式有惊人的了解。检查一下:http: //www.ndepend.com/。最重要的是,此工具将允许您查看没有任何直接调用者的方法。它还将向您显示相反的,程序集中(甚至程序集之间)任何方法的完整调用树。

Whatever tool you choose, it's not a task to take lightly. Especially if you're dealing with public methods on library type assemblies, as you may never know when an app is referencing them.

无论您选择哪种工具,都不能掉以轻心。特别是如果您正在处理库类型程序集上的公共方法,因为您可能永远不知道应用程序何时引用它们。

回答by mmiika

Resharper is good for this like others have stated. Be careful though, these tools don't find you code that is used by reflection, e.g. cannot know if some code is NOT used by reflection.

正如其他人所说,Resharper 对此有好处。但是要小心,这些工具不会找到反射使用的代码,例如无法知道某些代码是否没有被反射使用。

回答by mmiika

FXCop is a code analyzer... It does much more than find unused code. I used FXCop for a while, and was so lost in its recommendations that I uninstalled it.

FXCop 是一个代码分析器……它的作用远不止查找未使用的代码。我使用了 FXCop 一段时间,并且对它的建议非常迷惑,所以我卸载了它。

I think NDepend looks like a more likely candidate.

我认为 NDepend 看起来更有可能成为候选人。

回答by Dan

The truth is that the tool can never give you a 100% certain answer, but coverage tool can give you a pretty good run for the money.

事实是,该工具永远无法为您提供 100% 确定的答案,但覆盖率工具可以让您物有所值。

If you count with comprehensive unit test suite, than you can use test coverage tool to see exactly what lines of code were not executed during the test run. You will still need to analyze the code manually: either eliminate what you consider dead code or write test to improve test coverage.

如果您使用全面的单元测试套件,那么您可以使用测试覆盖工具来准确查看在测试运行期间未执行的代码行。您仍然需要手动分析代码:要么消除您认为的死代码,要么编写测试以提高测试覆盖率。

One such tool is NCover, with open source precursor on Sourceforge. Another alternative is PartCover.

其中一种工具是NCover,它是Sourceforge上的开源前身。另一种选择是PartCover

Check out this answeron stackoverflow.

在stackoverflow上查看这个答案

回答by Patrick from NDepend team

As pointed Jeff the tool NDependcan help to find unused methods, fields and types.

正如 Jeff 指出的那样,工具NDepend可以帮助找到未使用的方法、字段和类型。

To elaborate a bit, NDepend proposes to write Code Rule over LINQ Query (CQLinq). Around 200 default code rulesare proposed, 3 of them being dedicated to unused/dead codedetection

为了详细说明,NDepend 建议编写Code Rule over LINQ Query (CQLinq)。提出了大约200 个默认代码规则,其中 3 个专门用于未使用/死代码检测

Basically such a rule to detect unused method for example looks like:

基本上这样一个检测未使用方法的规则看起来像:

// <Name>Dead Methods</Name>
warnif count > 0 
from m in Application.Methods where !m.MethodsCallingMe.Any()
select m

NDepend rule to find unused methods (dead methods)

NDepend 规则来查找未使用的方法(死方法)

But this rule is naive and will return trivial false positives. There are many situations where a method is never called yet it is not unused (entry point, class constructor, finaliser...) this is why the 3 default rules are more elaborated:

但这条规则很幼稚,会返回微不足道的误报。在很多情况下,一个方法从未被调用过,但它也没有被使用(入口点、类构造函数、终结器……)这就是为什么 3 个默认规则更详细的原因:

NDepend integrates in Visual Studio 2017,2015, 2013, 2012, 2010, thus these rules can be checked/browsed/edited right inside the IDE. The tool can also be integrated into your CI process and it can build reportsthat will show rules violated and culprit code elements. NDepend has also a VS Team Services extension.

NDepend 集成在 Visual Studio 2017、2015、2013、2012、2010 中,因此可以在 IDE 中检查/浏览/编辑这些规则。该工具还可以集成到您的 CI 流程中,它可以构建报告,显示违反的规则和罪魁祸首的代码元素。NDepend 还有一个VS Team Services 扩展

If you click these 3 links above toward the source code of these rules, you'll see that the ones concerning types and methods are a bit complex. This is because they detect not only unused types and methods, but also types and methods used onlyby unused dead types and methods (recursive).

如果您单击上面这 3 个指向这些规则的源代码的链接,您会发现有关类型和方法的内容有点复杂。这是因为它们不仅检测未使用的类型和方法,还检测由未使用的死类型和方法(递归)使用的类型和方法。

This is static analysis, hence the prefix Potentiallyin the rule names. If a code element is used onlythrough reflection, these rules might consider it as unused which is not the case.

这是静态分析,因此规则名称中的前缀Potentially。如果代码元素通过反射使用,则这些规则可能会将其视为未使用,但事实并非如此。

In addition to using these 3 rules, I'd advise measuring code coverage by tests and striving for having full coverage. Often, you'll see that code that cannot be covered by tests, is actually unused/deadcode that can be safely discarded. This is especially useful in complex algorithms where it is not clear if a branch of code is reachable or not.

除了使用这 3 条规则之外,我还建议通过测试来衡量代码覆盖率并努力实现完全覆盖。通常,您会看到测试无法覆盖的代码实际上是可以安全丢弃的未使用/死代码。这在不清楚代码分支是否可达的复杂算法中尤其有用。

Disclaimer: I work for NDepend.

免责声明:我为 NDepend 工作。

回答by ramu

I have come across AXTools CODESMART..Try that once. Use code analyzer in reviews section.It will list dead local and global functions along with other issues.

我遇到了 AXTools CODESMART ..尝试一次。在评论部分使用代码分析器。它将列出死的本地和全局函数以及其他问题。

回答by Allen Marshall

I would also mention that using IOC aka Unity may make these assessments misleading. I may have erred but several very important classes that are instantiated via Unity appear to have no instantiation as far as ReSharper can tell. If I followed the ReSharper recommendations I would get hosed!

我还要提一下,使用 IOC 又名 Unity 可能会使这些评估产生误导。我可能弄错了,但就 ReSharper 而言,通过 Unity 实例化的几个非常重要的类似乎没有实例化。如果我遵循 ReSharper 的建议,我会被灌输!