Предупреждение CA2204 для указания имени типа в строковом литерале

Рассмотрим следующий код С#:

if (atr == null) throw new InvalidOperationException("No ContentProperty attribute found on type.");

При создании проекта "CA2204: литералы должны быть написаны правильно" предупреждение выдается из-за непризнанного слова "ContentProperty".

Мне известно, что я могу отключить правило (либо глобально, либо только для содержащего метода), либо создать собственный словарь анализа кода и добавить в него "ContentProperty" как распознанное слово. Однако ни одно из этих решений не кажется мне привлекательным. Ссылаясь на имя типа или члена класса в сообщении об исключении, в моем проекте очень много происходит, что представляет собой инфраструктуру приложения.

Имеет ли Code Analysis способ сказать, что слово/группа слов не предназначено для проверки орфографии, например, когда они окружены кавычками или чем-то еще? Или отключает предупреждение только по этому пути?

ОТВЕТЫ

Ответ 1

В Visual Studio 2017 † я продемонстрировал, что предупреждения анализа кода CA2204: литералы должны быть написаны правильно можно избежать, используя следующие дополнения к С# версии 6:

if (atr == null)
{
    throw new InvalidOperationException(
        $"No {nameof(ContentProperty)} attribute found on type.");
}

Вы также можете найти мой ответ на интерполяцию строк в Visual Studio 2015 и IFormatProvider (CA1305), чтобы избежать CA1305: укажите IFormatProvider, чтобы быть полезным.

&кинжал; Обратите внимание, что С# версии 6 был поставлен с Visual Studio 2013. Более новая версия Visual Studio (с более новой версией анализа кода) также может потребоваться, чтобы избежать этого предупреждения.

Ответ 2

Я бы использовал другой подход, так как сохранение пользовательского словаря может стать проблемой обслуживания: нет ссылки на фактический класс (в вашем примере ContentPropertyAttribute). Что произойдет, если кто-то переименует или удалит этот класс? Записи в пользовательских атрибутах должны быть синхронизированы вручную, что подвержено ошибкам.

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

throw new InvalidOperationException(string.Format("No {0} found on type.", typeof(ContentPropertyAttribute).Name);

Теперь у вас даже есть своя безопасность времени для вашего сообщения.

Ответ 3

В этой статье описывается, как создать пользовательский словарь для анализа кода: http://msdn.microsoft.com/en-us/library/bb514188.aspx

Создайте файл CustomDictionary.xml и добавьте его в свой проект. Задайте для свойства Build Action файла значение CodeAnalysisDictionary

Содержимое файла должно выглядеть следующим образом:

<Dictionary>
    <Words>
        <Recognized>
            <Word>ContentProperty</Word>
        </Recognized>
    </Words>
</Dictionary>

Как было предложено Dr Willy Apprentice в комментариях ниже, может быть хорошей идеей динамически генерировать словарь на основе архитектуры фреймворка.

Ответ 4

Есть ли в анализе кода способ сказать, что слово не предназначено для проверки орфографии, , например, когда оно окружено кавычками или что-то еще?

CA2204 только применяется к строковым литералам, т.е. строкам, жестко закодированным (в окружении кавычками). Отключение этого правила анализа кода не помешает CA проверять правописание на имена классов, публичные элементы или другие свойства кода.

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

Другой вариант - переместить строки с ошибкой в ​​файл Resource.resx. Однако у вас будет такая же проблема, если включена CA1703.