Удобный способ сгенерировать файл editorconfig по вашим требованиям

В предыдущем посте я рассказывал, как создать единое техническое пространство для соблюдения codestyle-конвенций внутри команды.

Это пространство включает настройки IDE (например, настройки правил code cleanup, автоматическую очистку кода при сохранении файлов), набор статических анализаторов и файл editorconfig, по которому работает функция очистки IDE и в котором задаются исключения для правил статических анализаторов.

Сегодня я хочу поделиться удобным способом генерации файла editorconfig для C# в Visual Studio 2022.

Для начала откройте диалоговое окно Options через меню Tools, затем выберите Text-Editor–C#–Code Style–General.

В открывшемся окне вы увидите список правил стиля кода с указанием их предпочтений (Preference) и уровня важности (Severity), а также визуальное отображение примеров настроек для каждого правила. Именно благодаря такому наглядному представлению я предпочитаю этот метод генерации editorconfig.

После выбора необходимых предпочтений для правил, установите для каждого из них соответствующий уровень важности (Severity).

Например, в слайде, где показаны настройки для Code block preferences, для параметра Preference braces выбрано значение Yes с уровнем важности Warning. Это означает, что если в проекте будет использована конструкция if без фигурных скобок, IDE выдаст предупреждение.

После настройки правил достаточно нажать Generate .editorconfig file from settings и сохранить файл в корне проекта.

Пост на LinkedIn

Спустя два месяца мой пул-реквест наконец принят и замержен в документацию .NET. Надеюсь, что уже в ближайшее время на learn.microsoft.com появится мой небольшой гайд по генерации юнит-тестов с использованием Copilot и Visual Studio 2022. А сейчас в разработке находится ещё один гайд

Используйте панель Toolbox в Visual Studio 2022

Панель Toolbox хорошо известна разработчикам, которые работали с WinForms - в ней располагались готовые компоненты.

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

Чтобы открыть панель, перейдите в View → Toolbox или используйте сочетание клавиш Ctrl+Alt+X.

Чтобы добавить сниппет, достаточно выделить нужные строки кода и перенести их в панель с помощью drag-n-drop. Затем, для удобства, можно переименовать сниппет.

После этого вы можете перетаскивать сниппеты (также с помощью drag-n-drop) в нужные участки кода в разных проектах и решениях.

Архитектура, которую я использую в проектах. Продолжение

Предыдущий пост об архитектуре на разных площадках собрал отличные вопросы, и я решил разобрать их подробнее в отдельной публикации.
Давайте вспомним основные требования

- Приложение должно легко покрываться тестами.
- Приложение должно без труда обновляться и переходить на новые версии .NET.
- Код должен быть простым.
- Поставщика данных должно быть легко заменить, например, с базы данных на внешний сервис.
- Не использовать библиотеки, которые влияют на архитектуру.

Эти требования ориентированы на практическое использование. Нет цели строго соответствовать DDD, CQRS, Event Sourcing и т.д.

Почему я против внешних библиотек, которые глубоко проникают в архитектуру

В целом, использование внешних библиотек — это всегда риск. Платные библиотеки могут существенно повысить стоимость поддержки проекта. Автор open source-библиотеки может потерять мотивацию, добавить вредоносный код или сделать проект платным. Конечно, можно сделать форк, но тогда поддержка и обновление лягут на вас. Если библиотека используется только в ограниченной части приложения, это приемлемо, но если она плотно интегрируется в архитектуру — это становится проблемой.
Такие библиотеки обычно используются для сокращения объёма кода, например, за счет рефлексии. Однако если вернуться к изначальным требованиям, такой цели не было. Не всегда "меньше кода" — это лучше, тем более сейчас IDE отлично помогают с автодополнением. Отказавшись от подобных библиотек, мы получаем преимущества: независимость проекта, удобство дебага и простоту навигации по коду.

Почему я использую юзкейсы, а не большие сервисы

В комментариях часто спрашивают, зачем создавать отдельный класс use case для каждого действия, если можно сделать один сервис с несколькими методами. Такой подход действительно не противоречит архитектурным требованиям — и раньше я тоже использовал сервисы. Но со временем сервисы разрастаются и превращаются в классы на 1000+ строк с десятками методов. Внутри появляются приватные методы, которые используются разными публичными, что вроде бы способствует переиспользованию, но на деле сильно увеличивает связность кода. Кроме того, такие сервисы часто имеют десятки зависимостей, что сильно усложняет тестирование.

Можно ли использовать базовые классы для use case или репозиториев?

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

EF и Repository

Существует распространённое мнение, что если мы используем EF, то не нужно создавать дополнительную абстракцию — ведь EF уже абстрагирует работу с БД. Но в этом случае мы получаем сильную зависимость от ORM, хотя можем захотеть заменить часть операций, например, отправлять данные в Kafka вместо сохранения в БД. В моей архитектуре работа с EF происходит только на уровне Infrastructure, внутри реализации репозитория (важно, у меня нет базового репозитория, каждый — независим).

Пост на LinkedIn

Какой длины должен быть метод?

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

Однако в некоторых случаях нам нужны конкретные числовые рекомендации. Например, для начинающих разработчиков числовое ограничение более практично. Также числовые ограничения удобны при настройке статических анализаторов и настройке флагов при создании пул-реквестов.

Ниже прямые цитаты из ключевых источников, которые чаще всего всплывают в дискуссиях о размере методов.

Роберт Мартин, «Чистый код»
«Первое правило функций — они должны быть маленькими. Второе правило функций — они должны быть ещё меньше… Желательно, чтобы длина функции не превышала 20 строк»

Стив Макконнел, «Совершенный код»
«…Время от времени реализация сложного алгоритма будет требовать создания более длинного метода, и тогда методу можно будет позволить вырасти до 100–200 строк… Десятилетия исследований говорят о том, что методы такой длины не более подвержены ошибкам, чем методы меньших размеров.»

Android Java Style Guide
«Методы должны быть небольшими и решать конкретную задачу. Если метод превышает 40 строк, подумайте, можно ли разбить его на части, не нарушив структуру программы.»

Я же придерживаюсь рекомендаций статического анализатора Meziontou - не более 60 строк кода. Для меня и моей команды это стало хорошей практикой.

Оптимизируем nullable-аннотации с помощью [NotNullWhen(true)]

Если вы используете nullable-аннотации в C#, скорее всего сталкивались с предупреждениями CS8602/CS8603.

Часть этих сообщений действительно помогает ловить потенциальные null-референции, однако в более сложных методах компилятор не всегда способен учесть пользовательские проверки и трактует значения как "возможно null", даже когда они проверены.

Эту проблему могут решить атрибуты из System.Diagnostics.CodeAnalysis, позволяющие формально описать контракты методов.

Ниже показан пример, как [NotNullWhen(true)] устраняет лишние предупреждения в классическом Try*-паттерне.

1. Без использования атрибута, получаем предупреждение

bool TryGetDomain(string? url, out string? domain)
{
    if (url is null || !url.Contains("://"))
    {
        domain = null;
        return false;
    }

    domain = url.Split("://")[1];
    return true;   // здесь domain гарантированно не null
}

if (TryGetDomain(link, out var d))
{
    Console.WriteLine(d.Length);   // Предупреждение CS8602 «возможен null»
}

2. С использованием атрибута [NotNullWhen(true)] анализатор понимает что при true, out-параметр не будет null.

bool TryGetDomain(
        string? url,
        [NotNullWhen(true)] out string? domain)
{
    if (url is null || !url.Contains("://"))
    {
        domain = null;
        return false;  // при false null допустим
    }

    domain = url.Split("://")[1];
    return true;   // при true null невозможен
}

if (TryGetDomain(link, out var d))
{
    Console.WriteLine(d.Length);   // без варнингов и лишних проверок
}

Зачем это нужно

Меньше проверок на null — сокращается объtм кода.
Явные контракты в сигнатуре — упрощается чтение и ревью.
Точнее статический анализ — компилятор концентрируется на реальных ошибках.


Другие атрибуты, которые стоит знать

[MaybeNullWhen(true)] — метод возвращает true, однако значение может быть null.

[NotNullIfNotNull("param")] — если входной параметр не null, результат тоже не будет null.

[MemberNotNull("Field")] — метод гарантирует инициализацию поля или свойства до выхода.

[DoesNotReturnIf(true)] — метод не возвращает управление при выполнении условия (обычно выбрасывает исключение).

Посты на LinkedIn, Medium

Как добавить юнит-тесты в легаси‑проект

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

Давайте рассмотрим несколько причин:

— Защита ключевой логики, ошибка в которой может повлечь финансовые потери. Представьте, что в методе спрятан сложный расчёт цены или процентной ставки. Тест гарантирует, что будущие изменения не сломают его.

— Быстрая отладка. Вместо настройки БД под определенный кейс, SMTP‑сервера и других сервисов, вы можете протестировать нужный кусок кода отдельно.

— Пошаговый рефакторинг. Полная переписка проекта — это риск. Вынося небольшие части в тестируемые единицы, вы получаете мгновенные плюсы и уверенность для более масштабных изменений в будущем.

Подход "Простой объект" (Humble Object)

Чтобы начать писать тесты, не нужна идеальная архитектура. С шаблоном Humble Object:

1. Выносите бизнес‑логику в отдельный класс без внешних зависимостей.
2. Оставляете доступ к базе, отправку email, логирование и прочую инфраструктуру в исходном методе.
3. Пишете тесты только для этого нового простого класса. Остальной код не меняется.

Пример

Вот пример контроллера, который смешивает вычисления с вызовами email, базы данных и логирования. Тестирование такого кода напрямую потребует замокать EF Core, DateTime.Now, SMTP и логгер одновременно

[HttpPost("create")]
public IActionResult Create(OrderDto dto)
{
    var customer = _db.Customers.Find(dto.CustomerId);
    var now = DateTime.Now;
    decimal subtotal = dto.Lines.Sum(l => l.Price * l.Qty);

    // Скидка на черную пятницу
    if (now.Month == 11 && now.Day >= 25 && now.Day <= 30)
        subtotal *= 0.8m;

    decimal vat = subtotal * 0.12m;
    decimal total = subtotal + vat;

    customer.Balance -= total;
    _db.SaveChanges();

    _smtp.Send("sales@corp", customer.Email,
                "Thanks for your order", $"Total = {total:C}");

    _log.Write($"{now:u} Order {dto.Id} for {customer.Id} = {total}");

    return Ok(new { id = dto.Id, total });
}

Выносим расчет цены в отдельный класс

public class OrderPricer
{
    private readonly IClock _clock;
    private const decimal VatRate = 0.12m;

    //  в .NET 8 и выше можно использовать встроенный TimeProvider вместо IClock
    public OrderPricer(IClock clock) => _clock = clock;

    public decimal CalculateTotal(IEnumerable<OrderLineDto> lines)
    {
        decimal subtotal = lines.Sum(l => l.Price * l.Qty);
        var now = _clock.UtcNow;

        // Скидка на черную пятницу
        if (now.Month == 11 && now.Day >= 25 && now.Day <= 30)
            subtotal *= 0.8m;

        decimal vat = subtotal * VatRate;
        return subtotal + vat;
    }
}

Пишем тесты

public class FixedClock : IClock
{
    public DateTime UtcNow { get; init; }
}

public class OrderPricerTests
{
    [Fact]
    public void CalculatesTotalWithVat_NoDiscount()
    {
        var clock = new FixedClock { UtcNow = new DateTime(2025, 7, 19) };
        var pricer = new OrderPricer(clock);

        var total = pricer.CalculateTotal(new[]
        {
            new OrderLineDto { Price = 100, Qty = 1 }
        });

        Assert.Equal(112m, total);
    }
    // остальные тесты
}

Сейчас контроллер просто связывает компоненты

[HttpPost("create")]
public IActionResult Create(OrderDto dto)
{
    var customer = _db.Customers.Find(dto.CustomerId);
    var pricer = new OrderPricer(_clock);
    decimal total = pricer.CalculateTotal(dto.Lines);

    customer.Balance -= total;
    _db.SaveChanges();

    _smtp.Send("sales@corp", customer.Email,
                "Thanks for your order", $"Total = {total:C}");
    _log.Write($"{_clock.UtcNow:u} Order {dto.Id} for {customer.Id} = {total}");

    return Ok(new { id = dto.Id, total });
}

Теперь вы можете начать тестировать легаси‑код сразу, без масштабного рефакторинга.
Достаточно просто вынести основную логику в небольшие классы, которые легко тестировать. Даже несколько тестов критических методов может начать приносить пользу.

Посты на LinkedIn, Medium