Есть ли обычное правило FxCop, которое будет обнаруживать неиспользуемые методы PUBLIC?

Ответ 1

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" Кодовые метрики о сцеплении, мертвом коде, дефектах дизайна и реорганизации. В статье также рассматривается обнаружение мертвых полей и типов.

(EDIT: сделанный ответ более понятен)

РЕДАКТИРОВАТЬ 11 июня 2012 года. Объясните новые возможности NDepend относительно неиспользуемого кода. Отказ от ответственности: я являюсь разработчиком этого инструмента.

Так как NDepend v4 выпущен в мае 2012 года, инструмент предлагает написать Code Rule over LINQ Query (CQLinq). Примерно 200 правил кода по умолчанию, 3 из которых посвящены обнаружению неиспользуемого/мертвого кода:

• Потенциально мертвые типы (следовательно, обнаружить неиспользуемый класс, структуру, интерфейс, делегат...)
• Потенциально мертвые методы (следовательно, обнаруживать неиспользуемый метод, ctor, свойство getter/setter...)
• Потенциально мертвые поля

Эти правила кода CQLinq более мощные, чем предыдущие CQL. Если вы нажмете эти 3 ссылки выше на исходный код этих правил, вы увидите, что те, которые относятся к типам и методам, немного сложны. Это связано с тем, что они обнаруживают не только неиспользуемые типы и методы, но также типы и методы, используемые только неиспользуемыми мертвыми типами и методами (рекурсивными).

Это статический анализ, поэтому префикс Потенциально в именах правил. Если элемент кода используется только через отражение, эти правила могут считать его неиспользованным, что не так.

В дополнение к использованию этих 3 правил я бы посоветовал измерить охват кода тестами и стремиться к полному охвату. Часто вы увидите, что код, который не может быть охвачен испытаниями, на самом деле неиспользуемый/мертвый код, который можно безопасно отбросить. Это особенно полезно в сложных алгоритмах, где неясно, доступна ли ветвь кода или нет.

Ответ 2

Если метод не используется, и публичный FxCop предполагает, что вы сделали его общедоступным для доступа к внешним файлам.

Если неиспользуемые общедоступные методы приводят к предупреждению FxCop о написании API-интерфейсов и тому подобному, это будет больно - вы получите множество предупреждений FxCop для методов, которые вы намерены использовать другими.

Если вам не нужно что-либо внешнее для доступа к вашей сборке /exe, рассмотрите поиск-замену public на internal. Ваше приложение будет работать одинаково, и FxCop сможет найти неотредактированные внутренние методы.

Если вам нужен внешний доступ, найдите, какие методы действительно необходимы для внешнего, и сделайте все остальное внутренним.

Любые методы, которые вы делаете внешне видимыми, также могут иметь модульные тесты.

Ответ 3

NDepend является вашим другом для такого рода вещей

Ответ 4

Как он узнает, что общественные методы не используются?

Помечая метод как общедоступный, он может быть доступен любым приложением, которое ссылается на вашу библиотеку.