Анализ кода С# .NET CA1822

Я запускаю Анализ кода и получаю это сообщение:

CA1822: Microsoft.Performance: параметр this (или Me в Visual Basic) CreateIntervalString(TimeSpan) никогда не используется. Пометьте член как статический (или Shared в Visual Basic) или используйте this/Me в теле метода или хотя бы одно средство доступа к свойству, если это необходимо.

Мой код:

private string CreateIntervalString(TimeSpan timeSpan)
{
    return timeSpan.ToString();
}

как я понял, поскольку функция CreateIntervalString не использует никаких членов класса, а использует только ввод timeSpan, VisualStudio рекомендует мне пометить ее как статическую.

Мои вопросы:

  1. Почему когда я помечаю его как статический, производительность повышается?
  2. Моя функция является частью библиотеки, которая должна быть потокобезопасной, предотвращает ли это метод маркировки как статический?
  3. У меня есть дополнительные частные функции, которые используют только свои входные данные и не используются ни для каких других членов класса, но я не получаю для них ту же ошибку.

Большое спасибо!

Примеры:

следующий метод выдает ошибку:

    private string CreateIntervalString(TimeSpan timeSpan)
    { 
          return timeSpan.ToString();
    }

а следующее нет:

    private DateTime ParseDateString(string dateTimeString)
    {
     // the years,monthe,days,hours,minutes and secondes found by the dateTimeString input        
      return new DateTime(years, months, days, hours, minutes, secondes);
    }

person RRR    schedule 26.06.2011    source источник
comment
Пожалуйста, покажите код, который вы удалили из ParseDateString - это может дать понять, почему этот метод не помечен.   -  person ClickRick    schedule 11.06.2016


Ответы (4)


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

  2. Поскольку вы не используете экземпляр из метода, это не влияет на состояние безопасности потоков. Поскольку метод использует только те данные, которые ему отправлены, он является потокобезопасным.

  3. Либо вы на самом деле используете какой-то член экземпляра в методах, либо в коде есть что-то, что потенциально может использовать какой-то член экземпляра, либо в коде есть что-то, что заставляет инструмент думать, что он это делает.

person Guffa    schedule 26.06.2011
comment
если производительность не улучшилась, почему эта ошибка была показана как ошибка Microsoft.Performence?, и моя функция является частной, и я использую ее только в своем внутреннем классе, поэтому в любом случае я не должен создавать экземпляр, чтобы использовать его... ? - person RRR; 26.06.2011
comment
@RRR: Ну, это должно быть классифицировано как что-то, и хотя сам вызов метода не влияет на производительность, необходимость создания экземпляра объекта будет. Даже если вам на самом деле никогда не нужно создавать экземпляр для использования метода, анализ кода не знает об этом, он может применять свои правила только к найденному коду. Кроме того, лучше следовать рекомендациям даже для кода, который используется только внутри класса. - person Guffa; 26.06.2011
comment
да, но если я помечаю метод как частный, компилятор должен знать, что я никогда не использую его вне класса, и я никогда не должен создавать из него экземпляр? - person RRR; 26.06.2011
comment
@RRR: Нет, этот вывод нельзя сделать, просто сделав метод закрытым. У вас все еще может быть общедоступный статический метод, который использует частный метод, и в этом случае для его использования потребуется создать экземпляр. - person Guffa; 26.06.2011
comment
У Microsoft/группы компиляторов твердое мнение о том, что представляет собой хорошие шаблоны программирования и дизайн программного обеспечения. Здесь я подумал, что следование стилю без статических методов и только объектов может стать краеугольным камнем хорошего дизайна. Нет, говорит компилятор. - person Prof. Falken; 09.08.2018

Сайт MSDN http://msdn.microsoft.com/en-us/library/ms245046.aspx дает ответ на аспект производительности

Если метод не помечен как статический, то текущий объект (this) будет проверяться на значение null средой выполнения. В большинстве случаев будет небольшая наблюдаемая разница, это правда, но если метод, который вызывается миллионы раз в секунду, может получить этот выигрыш, будучи статичным, то это может быть целесообразно.

person ClickRick    schedule 28.03.2014

  1. У статических функций на один аргумент меньше (скрытый аргумент this), поэтому теоретически они более эффективны.
  2. Безопасность потоков не имеет ничего общего с тем, является ли ваш метод статическим или нет. Вы можете сделать метод экземпляра небезопасным для потоков так же легко, как и статический метод.
  3. Не могли бы вы опубликовать некоторые из этих функций, чтобы мы могли их увидеть?
person Matti Virkkunen    schedule 26.06.2011

  1. В большинстве ситуаций вы не заметите разницы в производительности между статическими и нестатическими функциями. Теоретически тот факт, что они не могут быть виртуальными (и не использовать указатель "this" в качестве аргумента), делает их немного быстрее. Но опять же, не то, что вы обычно замечаете.
  2. Статика и потокобезопасность не связаны. Если метод был потокобезопасным до "статического", он будет потокобезопасным и после "статического".
  3. Я видел это раньше с некоторыми инструментами. Если дополнительные закрытые методы используются нестатическими методами, анализ кода предполагает, что их нельзя сделать статическими (даже если они не ссылаются на элементы). Если вы измените другие нестатические методы на статические (если можете), то, вероятно, вы получите такое же предупреждение.

Надеюсь, это поможет, Джон

person JohnD    schedule 26.06.2011