Существует ли пользовательское правило FxCop, которое обнаружит неиспользованные Открытые методы?

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 на Связи, Мертвом коде, Недостатках дизайна и Реинжиниринге. Статья также пробегается через обнаружение мертвых полей и типов.

(РЕДАКТИРОВАНИЕ: сделанный более понятный ответ)

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

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

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

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

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

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

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

Как это знало бы, что открытые методы не использованы?

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

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

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

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

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

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