Is there a custom FxCop rule that will detect unused PUBLIC methods?

Corey Trager picture Corey Trager · Sep 16, 2008 · Viewed 8.5k times · Source

I just tried FxCop. It does detect unused private methods, but not unused public. Is there a custom rule that I can download, plug-in that will detect public methods that aren't called from within the same assembly?

Answer

user7116 picture user7116 · Sep 16, 2008

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:

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.