Обнаружение и предотвращение ошибок форматирования в вашем коде
csharp dotnet aspnet dotnet-core

Обнаружение и предотвращение ошибок форматирования в вашем коде

9 января 2023 г.

Статический анализ кода — отличный инструмент для выявления некоторых видов ошибок в вашем коде, например, отсутствие удаления объектов, реализующих IDisposable. Кроме того, это помогает обеспечить и проверить, соответствует ли написанный код определенному стандарту, например, используя PascalCase для имен классов и camelCase для имен параметров.

В этом посте я покажу, как использовать Roslyn Analyzers с C# для обеспечения соблюдения некоторых стандартов качества кода и стиля кода в вашем коде, выдавая ошибки во время компиляции, если какие-либо правила не соблюдаются, и не позволяя коду быть защищенным. ветки репозитория.

Это вторая часть из трех статей о настройке единого стандарта форматирования в вашем редакторе кода. Прочитайте часть 1 здесь.

Анализаторы Roslyn

Roslyn — это платформа компилятора для .NET. Roslyn Analyzers — это инструменты статического анализа кода для Roslyn. Они проверяют ваш код на стиль, качество, ремонтопригодность и методы, которые могут вызвать ошибки. Они работают на основе предопределенных правил, серьезность которых можно настроить в файле EditorConfig.

В .NET 5 и более поздних версиях анализаторы включены по умолчанию. Чтобы включить их в более ранних версиях .NET, можно установить для свойства EnableNETAnalyzers значение true в файлах проекта, в которых используется проект SDK или установите их как пакет nuget:

Настройка EnableNETAnalyzers в файле проекта

<PropertyGroup>
  <EnableNETAnalyzers>true</EnableNETAnalyzers>
</PropertyGroup>

Установка в виде пакета nuget

```bash {linenos=false} Пакет установки Microsoft.CodeAnalysis.NetAnalyzers

### Enabling more analyzers

By default, only some rules are enabled, but we can configure this with the `AnalysisMode` property in the project file:

```xml
<PropertyGroup>
  <AnalysisMode>Recommended</AnalysisMode>
</PropertyGroup>

Разрешенные значения свойства AnalysisMode различаются для пакетов SDK для .NET 6 и .NET 5. Подробности здесь.

Как включить анализаторы .NET в VS Code

Анализаторы .NET по умолчанию работают в Visual Studio, но их необходимо включить в VS Code.

1. Перейдите к Файл > Настройки > Настройки.

2 – перейдите в раздел Расширения > Конфигурация C# или найдите omnisharp.enableRoslynAnalyzers.

3. Установите флажок Omnisharp: включить анализаторы Roslyn.

4. Перейдите к Расширения > Конфигурация C# или найдите omnisharp.enableEditorConfigSupport.

5 – Установите флажок Omnisharp: включить поддержку конфигурации редактора.

6 – Перезапустите расширение C#/Omnisharp или VS Code.

Типы правил

Анализаторы .NET имеют много категорий правил, но здесь я перечислю лишь некоторые из них, чтобы объяснить, как они взаимодействуют с функциями Visual Studio.

* Стандартное форматирование: параметры Editorconfig по умолчанию, такие как размер отступа и табуляции или пробелы; * Стиль кода — форматирование .NET: отступы, пробелы и перенос для конкретных языков. Например, используйте пробелы перед скобками в определениях методов. * Стиль кода — язык .NET: специальные правила C# и Visual Basic. Примеры: использование var вместо явного типа, предпочтение автоматических свойств вместо резервных полей. * Стиль кода – соглашения об именах: правила именования элементов кода, например использование PascalCase для имен классов и Async в конце имен асинхронных методов. * Стиль кода — Ненужный код: Правила для кода, который недоступен или неиспользуемые переменные, поля и т. д. * Качество кода: правила улучшения качества кода. Эти правила помогают идентифицировать код, который может вызвать ошибки или проблемы с безопасностью. Примеры: не объявляйте статические члены для универсальных типов, а перечисления должны иметь нулевое значение.

В приведенной ниже таблице показано, в каких функциях Visual Studio применяются исправления для этих типов правил.

| Исправления применены к | 🖹 Формат | 🧹 Очистка кода | 💡 Исправление кода | |----|:---:|:---:|:---:| | Стандартное форматирование | ✔️ | ✔️ | ✔️ | | Форматирование .NET | ✔️ | ✔️ | ✔️ | | Язык .NET | | ✔️ | ✔️ | | Соглашения об именах | | | ✔️ | | Ненужный код | | ❗ | ✔️ | | Качество кода | | | ❗ |

<цитата>

❗ Исправлены только некоторые правила.

💡 В предыдущем сообщении этой серии я объясняю, как настроить Visual Studio для применения это правила по очистке кода и как автоматически выполнять очистку кода при сохранении файла.

Применение правил в нашем коде

Правила настраиваются в файле EditorConfig (я объяснил это в Часть 1 этой серии), и их серьезность можно определить по трем уровням. Конфликты в правилах разрешаются в следующем порядке:

  1. Особые правила
  2. Правила категорий
  3. Все правила анализаторов

В приведенном ниже примере нарушение правил именования (IDE1006) будет считаться предупреждением, поскольку оно определено для конкретного правила:

# Defines that all analyzers rules are suggestions
dotnet_analyzer_diagnostic.severity = suggestion
# Defines that all Code Style analyzers rules are errors
dotnet_analyzer_diagnostic.category-Style.severity = error
# Defines that the rule IDE1006 is a warning
dotnet_diagnostic.IDE1006.severity = warning

1. Создайте файл EditorConfig из Visual Studio

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

В Visual Studio есть инструмент, который поможет вам настроить правила стиля кода в файле EditorConfig, показывая фрагмент кода, показывающий, как работают правила.

  1. Откройте Инструменты > Параметры > Текстовый редактор > С# > стиль кода;
  2. Настройте параметры стиля кода в подменю «Общие», «Форматирование» и «Именование». ⚠️ Не утруждайте себя установкой серьезности здесь; некоторые из них соблюдаются только Visual Studio и не применяются в сборке и других IDE;
  3. Вернувшись в подменю «Общие», нажмите Создать файл .editoconfig из настроек и сохраните его в папке, в которой находится файл решения (.sln).

<цитата>

⚠️ Если вы не используете Visual Studio, вы можете использовать образец и изменить его в соответствии со своими предпочтениями, например, из Рослин.

2. Настройте все проекты для использования рекомендуемых анализаторов .NET

Затем мы устанавливаем свойство AnalysisMode во всех файлах нашего проекта. Для .NET 6 SDK и более поздних версий установите значение Рекомендуется или Все.

<PropertyGroup>
  <AnalysisMode>Recommended</AnalysisMode>
</PropertyGroup>

3. Установить серьезность ошибки для всех правил анализаторов

Включите эту строку в наш EditorConfig, чтобы установить серьезность error для всех правил.

```баш {linenos=false}

Установить серьезность = ошибка для всех анализаторов

dotnet_analyzer_diagnostic.severity = ошибка

### 4. Correct the errors and override the severity for rules you don't want to use

If you are enabling the analyzers in an existing project, many errors will be shown. Correct them and override their severity if they don't apply for you or you won't correct them at the moment.


> 💡 In the [previous post of this series](https://hackernoon.com/how-to-set-up-a-formatting-standard-in-your-code-editor-and-why-you-should), I explain how to add fixers to Visual Studio's Code Cleanup. You can customize it to fix some rules violations.

#### Setting rules severity directly in EditorConfig file

```bash
# Other rules ...

# Set severity = none to the rules that are not important for me
dotnet_diagnostic.IDE0075.severity = none

# Set severity = warning to the rules that need to be resolved later
dotnet_diagnostic.IDE0047.severity = warning

Настройка серьезности правил из списка ошибок Visual Studio

Чтобы ошибки отображались в списке ошибок, щелкните правило правой кнопкой мыши и выберите Установить серьезность > Выберите серьезность. Конфигурация серьезности будет добавлена ​​в файл EditorConfig.

Установка серьезности правил в обозревателе решений Visual Studio

В обозревателе решений откройте Зависимости > Анализаторы под вашим проектом, затем щелкните правило правой кнопкой мыши и выберите Установить серьезность > Выберите серьезность. Конфигурация серьезности будет добавлена ​​в файл EditorConfig.

5. Применение правил при сборке

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

Для этого нам нужно включить свойство EnforceCodeStyleInBuild во всех файлах нашего проекта.

<PropertyGroup>
  <EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild>
</PropertyGroup>

Примеры применения правил

Правила, применяемые в Visual Studio

Правила, применяемые в VS Code

Правила применяются к команде сборки dotnet

Создание дополнительных соглашений об именах

Вот некоторые соглашения об именах языка C#:

| Символы | Конвенция | Пример | |----|----|----| | класс/запись/структура | ПаскальКейс | Физический адрес | | интерфейс | "I"+PascalCase | IWorkerQueue | | общественные члены | ПаскальКейс | Начать обработку событий | | частные/внутренние поля | ""+camelCase | _workerQueue | | статические поля | "s"+camelCase | s_workerQueue | | локальные переменные *️ | верблюжий чехол | Действителен | | параметры | верблюжий чехол | имя | | асинхронные методы | PascalCase+"Асинхронный" | GetStringAsync |

Подробнее здесь.

По умолчанию Visual Studio не создает соглашений об именах для статических полей, локальных переменных, параметров и асинхронных методов. Если мы хотим их использовать, мы должны вручную установить эти правила, как показано ниже.

<цитата>

*️ Не указано в документах, но Roslyn использует это соглашение. р>

Создание соглашения об именах для асинхронных методов

dotnet_naming_rule.async_methods_should_be_pascalcase_async.severity = error
dotnet_naming_rule.async_methods_should_be_pascalcase_async.symbols = async_methods
dotnet_naming_rule.async_methods_should_be_pascalcase_async.style = pascalcase_async

dotnet_naming_symbols.async_methods.applicable_kinds = method
dotnet_naming_symbols.async_methods.applicable_accessibilities = *
dotnet_naming_symbols.async_methods.required_modifiers = async

dotnet_naming_style.pascalcase_async.required_suffix = Async
dotnet_naming_style.pascalcase_async.capitalization = pascal_case

Создание соглашения об именах для локальных переменных и параметров

dotnet_naming_rule.locals_and_parameters_should_be_pascal_case.severity = error
dotnet_naming_rule.locals_and_parameters_should_be_pascal_case.symbols = locals_and_parameters
dotnet_naming_rule.locals_and_parameters_should_be_pascal_case.style = camel_case

dotnet_naming_symbols.locals_and_parameters.applicable_kinds = parameter, local

dotnet_naming_style.camel_case.capitalization = camel_case

Как игнорировать правило CA1707 (идентификаторы не должны содержать символы подчеркивания) в тестовых проектах

В некоторых соглашениях по именованию тестовых методов используется подчеркивание. Если это ваш случай, вы получите нарушение правила CA1707.

Чтобы отключить правило только для тестового проекта, создайте файл с именем GlobalSuppressions.cs в корне вашего тестового проекта с приведенным ниже содержимым.

using System.Diagnostics.CodeAnalysis;

[assembly: SuppressMessage("Naming", "CA1707:Identifiers should not contain underscores", Justification = "Not applicable for test names", Scope = "module")]

Сторонние анализаторы

Существуют сторонние анализаторы, которые могут иметь дополнительные правила, которые могут быть полезны. Вот некоторые из них:

Ссылки и ссылки

Понравился этот пост?

Я публикую дополнительный контент в своем личном блоге. Нажмите здесь, чтобы посмотреть.

:::информация Также опубликовано здесь.

:::

Оригинал

Recent Post

Categories

PREVIOUS ARTICLE
NEXT ARTICLE