当前位置：文江博客话题详情

是否有自定义 FxCop 规则可以检测未使用的 PUBLIC 方法？

发布于 2024-07-05 10:31:32 字数 88 浏览 11 评论 0原文

我刚刚尝试过 FxCop。它确实检测未使用的私有方法，但不检测未使用的公共方法。是否有我可以下载的自定义规则，插件可以检测未从同一程序集中调用的公共方法？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

土豪 2024-07-12 10:31:32

Corey，我对使用 FxCop 的回答假设您有兴趣删除未使用的私有成员，但是要解决其他情况下的问题，您可以尝试使用 NDepend。以下是一些用于检测未使用的公共成员的 CQL（改编自下面列出的文章）：

// <Name>Potentially unused methods</Name>
WARN IF Count > 0 IN SELECT METHODS WHERE
 MethodCa == 0 AND            // Ca=0 -> No Afferent Coupling -> The method 
                              // is not used in the context of this
                              // application.

 IsPublic AND                 // Check for unused public methods

 !IsEntryPoint AND            // Main() method is not used by-design.

 !IsExplicitInterfaceImpl AND // The IL code never explicitely calls 
                              // explicit interface methods implementation.

 !IsClassConstructor AND      // The IL code never explicitely calls class
                              // constructors.

 !IsFinalizer                 // The IL code never explicitely calls
                              // finalizers.

来源：Patrick Smacchia 的“关于耦合、死代码、设计缺陷和重新设计的代码度量”文章。还讨论了检测死字段和类型。

（编辑：使答案更容易理解）

2012 年 6 月 11 日编辑：解释有关未使用代码的新 NDepend 设施。自 2012年

5 月发布 NDepend v4 以来，该工具建议编写 LINQ 查询的代码规则 (CQLinq)。大约建议了 200 个默认代码规则，其中 3 个专门用于未使用/死代码检测：

潜在死类型（因此检测未使用的类、结构、接口、委托... )
潜在死方法（因此检测未使用的方法、ctor、属性 getter/setter...)
潜在死字段

这些 CQLinq 代码规则比以前的 CQL 更强大。如果您点击上面的这 3 个链接查看这些规则的源代码，您会发现涉及类型和方法的内容有点复杂。这是因为它们不仅检测未使用的类型和方法，而且还检测仅由未使用的死类型和方法（递归）使用的类型和方法。

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

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

Corey, my answer of using FxCop had assumed you were interested in removing unused private members, however to solve the problem with other cases you can try using NDepend. Here is some CQL to detect unused public members (adapted from an article listed below):

// <Name>Potentially unused methods</Name>
WARN IF Count > 0 IN SELECT METHODS WHERE
 MethodCa == 0 AND            // Ca=0 -> No Afferent Coupling -> The method 
                              // is not used in the context of this
                              // application.

 IsPublic AND                 // Check for unused public methods

 !IsEntryPoint AND            // Main() method is not used by-design.

 !IsExplicitInterfaceImpl AND // The IL code never explicitely calls 
                              // explicit interface methods implementation.

 !IsClassConstructor AND      // The IL code never explicitely calls class
                              // constructors.

 !IsFinalizer                 // The IL code never explicitely calls
                              // finalizers.

Source: Patrick Smacchia's "Code metrics on Coupling, Dead Code, Design flaws and Re-engineering. The article also goes over detecting dead fields and types.

(EDIT: made answer more understandable)

EDIT 11th June 2012: Explain new NDepend facilities concerning unused code. Disclaimer: I am one of the developer of this tool.

Since NDepend v4 released in May 2012, the tool proposes to write Code Rule over LINQ Query (CQLinq). Around 200 default code rules are proposed, 3 of them being dedicated to unused/dead code detection:

Potentially dead Types (hence detect unused class, struct, interface, delegate...)
Potentially dead Methods (hence detect unused method, ctor, property getter/setter...)
Potentially dead Fields

These CQLinq code rules are more powerful than the previous CQL ones. 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 only by unused dead types and methods (recursive).

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

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/dead code 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.

回复收藏 0 原文