Существует ли пользовательское правило FxCop, которое обнаруживает неиспользуемые методы PUBLIC?
Я только что попробовал FxCop. Он обнаруживает неиспользуемые приватные методы, но не неиспользуемые публичные. Есть ли пользовательское правило, которое я могу скачать, подключаемый модуль, который будет определять публичные методы, которые не вызываются из одной и той же сборки?
4 ответа
Кори, мой ответ об использовании 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.
Источник: Патрик Смаккья "Метрики кода по сцеплению, мертвому коду, недостаткам дизайна и реинжинирингу". В статье также рассматривается обнаружение мертвых полей и типов.
(РЕДАКТИРОВАТЬ: сделал ответ более понятным)
РЕДАКТИРОВАТЬ 11 июня 2012 г.: Объяснить новые возможности NDepend, касающиеся неиспользуемого кода. Отказ от ответственности: я один из разработчиков этого инструмента.
Начиная с выпуска NDepend v4 в мае 2012 года, инструмент предлагает написать правило кода поверх LINQ Query (CQLinq). Предложено около 200 правил кода по умолчанию, 3 из которых посвящены обнаружению неиспользуемого / мертвого кода:
- Потенциально мертвые типы (следовательно, обнаружение неиспользуемого класса, структуры, интерфейса, делегата...)
- Потенциально мертвые методы (следовательно, обнаружение неиспользуемого метода, ctor, свойства getter/setter...)
- Потенциально мертвые поля
Эти правила кода CQLinq являются более мощными, чем предыдущие правила CQL. Если вы нажмете эти 3 ссылки выше на исходный код этих правил, вы увидите, что те, которые касаются типов и методов, немного сложны. Это потому, что они обнаруживают не только неиспользуемые типы и методы, но также типы и методы, используемые только неиспользуемыми мертвыми типами и методами (рекурсивные).
Это статический анализ, отсюда и префикс Потенциально в именах правил. Если элемент кода используется только для отражения, эти правила могут рассматривать его как неиспользуемый, что не так.
В дополнение к использованию этих 3 правил, я бы посоветовал измерять покрытие кода тестами и стремиться к полному охвату. Часто вы увидите, что код, который не может быть покрыт тестами, на самом деле является неиспользованным / мертвым кодом, который можно безопасно отбросить. Это особенно полезно в сложных алгоритмах, где неясно, достижима ли ветвь кода или нет.
Если метод не используется и общедоступный FxCop предполагает, что вы сделали его общедоступным для доступа к внешним объектам.
Если неиспользуемые общедоступные методы приводят к написанию API-предупреждений FxCop и тому подобное, это будет проблемой - вы получите множество предупреждений FxCop для методов, которые вы намерены использовать другие.
Если вам не нужно ничего внешнего для доступа к вашей сборке / exe, подумайте о поиске замены public с internal, Ваше приложение будет работать так же, и FxCop сможет найти внутренние методы, на которые нет ссылок.
Если вам нужен внешний доступ, найдите, какие методы действительно необходимы для внешнего, и сделайте все остальное внутренним.
Любые методы, которые вы делаете внешне видимыми, также могут иметь модульные тесты.
Как он узнает, что публичные методы не используются?
Отметив метод как общедоступный, он может быть доступен любому приложению, которое ссылается на вашу библиотеку.