Найкраща практика позначити метод, який викликається через рефлексію?

У нашому програмному забезпеченні є кілька класів, які слід динамічно знаходити за допомогою рефлексії. Усі класи мають конструктор з певним підписом, за допомогою якого код відображення створює об'єкти.
Однак, коли хтось перевіряє, чи посилається на метод (наприклад, через Visual Studio Code Lens), посилання через відображення не враховуються. Люди можуть пропустити свої посилання та видалити (або змінити), мабуть, невикористані методи.

Як слід позначити / документувати методи, які слід викликати через рефлексію?

В ідеалі метод повинен бути позначений таким чином, щоб і колеги, і Visual Studio / Roslyn та інші автоматизовані інструменти «бачили», що метод повинен бути викликаний за допомогою рефлексії.

Я знаю два варіанти, які ми можемо використовувати, але обидва не дуже задовольняють. Оскільки Visual Studio не може знайти посилання:

• Використовуйте спеціальний атрибут та позначте конструктор цим атрибутом.
  • Проблема полягає в тому, що властивості Attribute не можуть бути посиланням на метод, тому конструктор все одно покаже, що має 0 посилань.
  • Колеги, не знайомі зі спеціальним атрибутом, ймовірно, проігнорують його.
  • Перевагою мого теперішнього підходу є те, що частина відображення може використовувати атрибут для пошуку конструктора, який він повинен викликати.
• Використовуйте коментарі для документування того, що метод / конструктор призначений викликати через відображення.
  • Автоматизовані інструменти ігнорують коментарі (і це можуть зробити і колеги).
  • Коментарі XML Документація може використовуватися для того, щоб Visual Studio рахував додаткове посилання на метод / конструктор:
    Нехай це MyPluginбуде клас, конструктор якого потрібно викликати через відображення. Припустимо, виклик коду відображення шукає конструкторів, які берутьint параметр. Наступна документація робить те, що кодовий об'єктив показує конструктор, який має 1 посилання:
    /// <see cref="MyPlugin.MyPlugin(int)"/> is invoked via reflection

Які кращі варіанти існують?
Яка найкраща практика для маркування методу / конструктора, який повинен бути викликаний за допомогою рефлексії?

Поєднання запропонованих рішень:

• Використовуйте теги документації XML для документування того, що конструктор / метод викликається через відображення.
  Це має пояснити передбачуване використання колегам (і моєму майбутньому самому).
• Використовуйте 'трюк' через <see>-tag, щоб збільшити кількість відліку для конструктора / методу.
  Це робить, що лінза коду та посилання на пошук показують, що конструктор / метод посилається.
• Повідомлення за допомогою Решарпера UsedImplicitlyAttribute
  • Resharper - це фактично стандарт і [UsedImplicitly] має саме передбачувану семантику.
  • Ті, хто не використовує Resharper, можуть встановлювати анотації JetBrains ReSharper через NuGet:
    PM> Install-Package JetBrains.Annotations.
• Якщо це приватний метод, і ви використовуєте аналіз коду Visual Studio, використовуйте SupressMessageAttributeдля повідомлення CA1811: Avoid uncalled private code .

Наприклад:

class MyPlugin
{
    /// <remarks>
    /// <see cref="MyPlugin.MyPlugin(int)"/> is called via reflection.
    /// </remarks>
    [JetBrains.Annotations.UsedImplicitly]
    public MyPlugin(int arg)
    {
        throw new NotImplementedException();
    }

    /// <remarks>
    /// <see cref="MyPlugin.MyPlugin(string)"/> is called via reflection.
    /// </remarks>
    [JetBrains.Annotations.UsedImplicitly]
    [System.Diagnostics.CodeAnalysis.SuppressMessage(
        "Microsoft.Performance", "CA1811:AvoidUncalledPrivateCode",
        Justification = "Constructor is called via reflection")]
    private MyPlugin(string arg)
    {
        throw new NotImplementedException();
    }
}

Рішення надає призначене використання конструктора як людським читачам, так і 3 системам статичного аналізу коду, які найбільш використовуються для C # та Visual Studio.
Мінус полягає в тому, що як коментар, так і одна чи дві примітки можуть здатися трохи зайвими.

У мене ніколи не було цієї проблеми в проекті .Net, але у мене регулярно виникає однакова проблема з проектами Java. Мій звичайний підхід - це використання@SuppressWarnings("unused") анотацію, додаючи коментар, пояснюючи, чому (документування причини відключення будь-яких попереджень є частиною мого стандартного стилю коду - будь-який час, коли компілятор не може щось з'ясувати, я припускаю, що це ймовірно, що людина може боротися теж). Це має перевагу в автоматичному забезпеченні того, що інструменти статичного аналізу усвідомлюють, що код не повинен мати прямих посилань, а також детальну причину для читачів людини.

C # еквівалент Java @SuppressWarningsє SuppressMessageAttribute. Для приватних методів можна використовувати повідомлення CA1811: уникати незатребуваного приватного коду ; наприклад:

class MyPlugin
{
    [System.Diagnostics.CodeAnalysis.SuppressMessage(
        "Microsoft.Performance", "CA1811:AvoidUncalledPrivateCode",
        Justification = "Constructor is called via reflection")]
    private MyPlugin(int arg)
    {
        throw new NotImplementedException();
    }
}

Альтернативою документування було б тестування одиниць, що забезпечують успішне виконання дзвінків для відображення.

Таким чином, якщо хтось змінить або видалить методи, які ваш процес складання / тестування повинен сповістити вас про те, що ви щось порушили

Ну, не бачачи свого коду, це виглядає так, що це було б хорошим місцем для введення певної спадщини. Може бути віртуальний або абстрактний метод, який може викликати конструктор цих класів? Якщо ви метод, який ви намагаєтеся позначити, - це лише конструктор, то ви справді намагаєтесь позначити клас, а не метод, так? Щось я робив для позначення класів - це зробити порожній інтерфейс. Тоді інструменти перевірки коду та рефакторинг можуть шукати класи, що реалізують інтерфейс.