我要重构一个大型 C# 应用程序，我发现很多函数从未使用过。如何检查未使用的代码，以便删除所有未使用的函数？
【问题讨论】：
标签： c# .net refactoring
是的，ReSharper 可以做到这一点。右键单击您的解决方案并选择“查找代码问题”。结果之一是“未使用的符号”。这将向您显示未使用的类、方法等。
【讨论】：
这是一个很好的问题，但请注意，您在这里涉足危险水域。当您删除代码时，您必须确保经常编译和测试。
想到一个很棒的工具：
NDepend - 这个工具真是太棒了。摸索需要一点时间，在最初的 10 分钟之后，我认为大多数开发人员只会说“去死吧！”并删除该应用程序。一旦你对 NDepend 有一个好的感觉，它就会让你对你的应用程序是如何耦合的有惊人的洞察力。看看：http://www.ndepend.com/。最重要的是，此工具将允许您查看没有任何直接调用者的方法。它还将向您展示相反的情况，即程序集中（甚至程序集之间）任何方法的完整调用树。
无论您选择何种工具，都不能掉以轻心。尤其是在处理库类型程序集上的公共方法时，因为您可能永远不知道应用何时引用它们。
【讨论】：
正如其他人所说，Resharper 对此有好处。不过要小心，这些工具不会找到反射使用的代码，例如无法知道某些代码是否未被反射使用。
【讨论】：
正如 Jeff 所指出的，工具 NDepend 可以帮助查找未使用的方法、字段和类型。
为了详细说明，NDepend 建议写成Code Rule over LINQ Query (CQLinq)。提出了大约200 default code rules，其中 3 个专门用于未使用/死代码检测
例如，检测未使用方法的规则基本上如下所示：
// <Name>Dead Methods</Name>
warnif count > 0
from m in Application.Methods where !m.MethodsCallingMe.Any()
select m
但这条规则很幼稚，会返回微不足道的误报。在很多情况下，一个方法从未被调用但它未被使用（入口点、类构造函数、终结器...），这就是为什么 3 个默认规则更加详细的原因：
NDepend 集成在 Visual Studio 2017、2015、2013、2012、2010 中，因此这些规则可以是checked/browsed/edited right inside the IDE。该工具还可以集成到您的 CI 流程中，它可以构建reports，它将显示违反的规则和罪魁祸首代码元素。 NDepend 还有一个VS Team Services extension。
如果你点击上面这3个链接看这些规则的源代码，你会发现关于类型和方法的部分有点复杂。这是因为它们不仅检测未使用的类型和方法，还检测仅未使用的死类型和方法使用的类型和方法（递归）。
这是静态分析，因此规则名称中的前缀Potentially。如果代码元素仅通过反射使用，则这些规则可能会将其视为未使用，但事实并非如此。
除了使用这 3 条规则之外，我还建议通过测试来衡量代码覆盖率，并努力实现全面覆盖。通常，您会看到测试无法覆盖的代码实际上是可以安全丢弃的未使用/死代码。这在不清楚代码分支是否可达的复杂算法中特别有用。
免责声明：我为 NDepend 工作。
【讨论】：
我还要提到，使用 IOC aka Unity 可能会使这些评估产生误导。我可能犯了错误，但据 ReSharper 所知，通过 Unity 实例化的几个非常重要的类似乎没有实例化。如果我遵循 ReSharper 的建议，我会被灌输！
【讨论】：
ReSharper 在查找未使用的代码方面做得很好。
在 VS IDE 中，您可以右键单击定义并选择“查找全部” References'，虽然这只适用于解决方案级别。
【讨论】：
事实是，该工具永远无法为您提供 100% 确定的答案，但覆盖率工具可以为您带来不错的收益。
如果您算上全面的单元测试套件，那么您可以使用测试覆盖率工具准确查看在测试运行期间哪些代码行没有执行。您仍然需要手动分析代码：消除您认为无效的代码或编写测试以提高测试覆盖率。
这样的工具之一是NCover，在Sourceforge 上有开源先驱。另一种选择是PartCover。
在 stackoverflow 上查看这个 answer。
【讨论】：
我遇到过 AXTools CODESMART.. 尝试一次。 在评论部分使用代码分析器。它将列出无效的本地和全局函数以及 其他问题。
【讨论】：
FXCop 是一个代码分析器...它的功能远不止查找未使用的代码。我使用了 FXCop 一段时间，但对它的建议迷失了方向，所以我卸载了它。
我认为 NDepend 看起来更有可能成为候选人。
【讨论】：