Поведение анализа кода CA1062

У меня есть следующий метод расширения для строк:

public static bool IsNullOrEmpty(this string target)
{
    return string.IsNullOrEmpty(target);
}

... и в коде я использую его следующим образом:

public static string DoSomethingOnString(this string target)
{
    if (target.IsNullOrEmpty())
        return target;

    target = target.Trim();  //This line causes CA1062 violation

    return target;
}

Теперь, если я выполню анализ кода на этом, я получу нарушение правила CA1062. Но если я изменю код на:

public static string DoSomethingOnString(this string target)
{
    if (string.IsNullOrEmpty(target))  //CHANGED LINE
        return target;

    target = target.Trim();  //This line DOES NOT cause CA1062 violation anymore

    return target;
}

... тогда все в порядке.

Почему он думает, что я не проверяю нулевое условие в первом примере? Проверяется ли только для string.IsNullOrEmpty или string.IsNullOrWhiteSpace? Есть ли способ заставить CA распознавать мой метод расширения, или мне нужно подавить это правило?

ОБНОВЛЕНИЕ: Если у вас возникла та же проблема, вы можете проголосовать за элемент обратной связи, который я отправил в MS Connect: правило анализа кода CA1062 вызывает ложную тревогу

1 ответ

Решение

Почему он думает, что я не проверяю нулевое условие в первом примере?

Проще говоря, FxCop не понимает, что если ваш IsNullOrEmpty метод расширения делает то же самое, что string.IsNullOrEmpty, Он не понимает, что если target нулевой, IsNullOrEmpty вернусь true и ваш метод выйдет. В основном я подозреваю, что он имеет встроенные знания string.IsNullOrEmpty, Скорее всего, здесь контракты кода будут иметь успех, так как я считаю, что FxCop выполняет лишь относительно поверхностную проверку того, что делает ваш код, по сравнению с глубокими рассуждениями о контрактах кода. Вы могли бы украсить свой IsNullOrEmpty метод с ValidatedNotNullAttribute сообщить FxCop, что происходит.

public static bool IsNullOrEmpty([ValidatedNotNullAttribute] this string target)
{
    return string.IsNullOrEmpty(target);
}
//The naming is important to inform FxCop
sealed class ValidatedNotNullAttribute : Attribute { }

Это всего лишь пример того, как анализ кода иногда может слишком критиковать. Это то, что я видел почти со всеми инструментами анализа кода, которые я использовал. Ваш выбор, как правило, соответствует:

  • Измените свой код, чтобы обойти инструмент анализа кода, даже если он был хорошо до
  • Подавить правила на определенных сайтах, после проверки каждого из них вручную
  • Подавить целые правила, если они часто дают ложные срабатывания
  • Отказаться от инструмента анализа кода полностью

Вы также должны регистрировать ошибку или запрос функции, конечно...

Похоже, они наконец-то добрались до того, чтобы исправить это в анализаторах roslyn.

Отчет об ошибке здесь:https://github.com/dotnet/roslyn-analyzers/issues/2369

Другие вопросы по тегам