Исключения не для управления потоком

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

Решение — использовать Result Pattern. Возврат объекта с полями IsSuccess или IsError, Value и Error делает API предсказуемым, код чище, тесты проще и повышает производительность.

Уже есть готовые NuGet-пакеты вроде FluentResults, CSharpFunctionalExtensions, Ardalis Result и error-or, но реализовать такой паттерн можно и самостоятельно.

Здесь лучший гайд по тому, как использовать Result Pattern в реальных приложениях

👉 @KodBlog

Топ-3 встроенных обобщённых делегата в C#: Func, Action и Predicate

Делегаты — это указатели на функции. Они помогают в коммуникации и колбэках.

В .NET есть три встроенных обобщённых делегата:

1) Func: принимает обобщённый вход и возвращает обобщённый выход
2) Action: принимает обобщённый вход и ничего не возвращает
3) Predicate: принимает обобщённый вход и всегда возвращает Boolean

Эти обобщённые делегаты активно используются во встроенных классах .NET,
и мы можем применять их, чтобы писать делегаты короче.

Хотите увидеть их на реальном примере?

- Создаём класс Student с некоторыми свойствами
- Формируем список объектов типа Student
- Добавляем данные

Некоторые методы LINQ используют делегаты:

- Метод Select принимает Func
- Метод ForEach принимает Action
- Метод FindAll принимает Predicate

А как часто вы используете их в своём коде?🍜

👉 @KodBlog

Знали ли вы, что можно создать гиперссылку, которая откроет Visual Studio и сразу клонирует любой git-репозиторий?

Это очень просто, вот пример: https://vs-open.link/git-clone

👉 @KodBlog

Новая C#-библиотека RCParsing, которая предлагает гибридный подход к обработке сложных синтаксисов с отступами.

Разработчики отмечают, что традиционные инструменты часто не справляются с такими задачами, а использование барьерных токенов значительно улучшает качество парсинга. В качестве примера приводится разбор YAML.

Подробнее в статье

👉 @KodBlog

Тонкое, но мощное дополнение в C# 14:

(которое снизит количество NullReferenceException)

Null-conditional assignment (null-условное присваивание).

Этот оператор позволяет присвоить значение члену или элементу объекта только в том случае, если сам объект не равен null.

Это небольшое изменение, но оно может сильно повлиять на читаемость и безопасность кода.

Почему это полезно:

Убирает повторяющиеся проверки на null перед присваиванием.

Упрощает код, делая его легче для понимания.

Безопасно пропускает присваивание, если целевой объект равен null, тем самым избегая NullReferenceException.

См. пример кода

👉 @KodBlog

Лучший редактор изображений

👉 @KodBlog

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

Это — кешировать (почти) всё!

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

Преимущества кеширования:

- более быстрое получение данных
- снижение нагрузки на основные хранилища
- улучшение пользовательского опыта

Не ограничивайся только кешированием запросов к базе данных, ведь чтение из кеша гораздо быстрее, чем вызов API.

Как решить, что кешировать?

Лучше спросить себя: а почему бы это не закешировать?

Добавление кеша имеет свою цену, поэтому для каждого кандидата нужно оценить:

- будет ли доступ через кеш быстрее
- стоит ли хранить эти данные
- как часто нужно валидировать
- сколько обращений придётся на одну запись в кеше
- локальный или общий кеш нужен

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

Чтобы оценить эффективность кеша, можно отслеживать метрики, например cache misses.

Популярные стратегии кеширования:

🔸Cache-Aside
Приложение само управляет чтением и записью в кеш. При cache miss данные берутся из основного хранилища и добавляются в кеш.

🔸Read-Through
При cache miss кеш автоматически подгружает данные из основного хранилища. Это упрощает работу, так как кеш сам обрабатывает промахи.

🔸Write-Around
Данные пишутся напрямую в основное хранилище, минуя кеш. Полезно, когда записи происходят часто, а чтения — реже.

🔸Write-Back
Сначала данные пишутся в кеш, а позже синхронизируются с основным хранилищем. Снижает количество операций записи, но есть риск потери данных, если синхронизация не успеет выполниться.

🔸Write-Through
Данные одновременно записываются и в кеш, и в основное хранилище. Обеспечивает консистентность, но может увеличивать задержку записи. Подходит там, где критична целостность данных.

👉 @KodBlog

Как проще всего запускать фоновые задачи в .NET?

Фоновые задачи — это процессы или операции, которые выполняются независимо от основного потока выполнения программы или приложения.

Обычно такие задачи работают в фоне, часто без прямого взаимодействия с пользователем, и могут выполнять различные функции, например:

отправка уведомлений

периодические задачи

задачи по расписанию

обработка сообщений

асинхронная обработка

обработка данных в реальном времени

Для этого в .NET можно использовать IHostedService.

Он содержит два метода:

- StartAsync
- StopAsync

Мы можем добавить в него нужное действие, достаточно зарегистрировать этот сервис в Program и всё будет готово.

Такой подход подходит для простых фоновых задач. Для более продвинутых сценариев можно использовать следующие NuGet-пакеты:

- Hangfire
- Quartz

👉 @KodBlog

Вышла онлайн IDE для .NET

Теперь приложения на C# и XAML можно писать прямо в браузере. 👨‍💻

IDE работает на WebAssembly, поддерживает drag-and-drop UI, сохранение проектов в облако или на ПК и компиляцию через Roslyn прямо в клиенте.

Запуск выполняется в отдельном iframe, чтобы интерфейс не подвисал, а в планах - автодополнение кода, AI-ассистент и шэринг проектов.

Попробовать можно на xaml.io

подробнее — Habr

👉 @KodBlog

Примеры полнотекстового поиска в Entity Framework:

Если ваша СУБД поддерживает эту возможность и вам действительно нужен поиск с подстановочными символами, рассмотрите использование полнотекстового поиска для более эффективных запросов.

// Полнотекстовый поиск по связанным терминам и словоформам  
// (например, "climate change", "climatic changes").
var resultsFreeText = context
    .Articles
    .Where(a => EF.Functions.FreeText(a.Content, "climate change")).ToList();


// Полнотекстовый поиск с операторами (AND, OR, NEAR) для точного совпадения фразы.
var resultsContains = context
    .Articles
    .Where(a => EF.Functions.Contains(a.Content, "climate change")).ToList();

👉 @KodBlog

Как на самом деле выполняется C#-код?

1. Вы пишете .cs-файл.

2. Компилятор (Roslyn) преобразует его в IL (Intermediate Language — промежуточный язык).

3. IL сохраняется в сборках (.dll / .exe).

Во время выполнения CLR :

- загружает сборки,

- проверяет IL на безопасность,

- компилирует «горячие» участки кода в машинные инструкции через JIT-компилятор.

CLR также обеспечивает сборку мусора, управление памятью и доступ к базовой библиотеке классов (System.*).

В итоге ваш C#-код работает как эффективный машинный код, сохраняя при этом типобезопасность, переносимость и удобство разработки.

Понимание этого пайплайна помогает при отладке проблем с производительностью, работе с зависимостями из NuGet и выборе между JIT- и AOT-компиляцией.

👉 @KodBlog

На GitHub есть репозиторий free-programming-books, где собрано более 4000 бесплатных книг, 2000 курсов и других полезных ресурсов по программированию

Для удобства поиска можно использовать этот инструмент

Этот проект - яркий пример силы опенсорс сообщества, который из клона списка со StackOverflow стал одним из самых популярных на GitHub ✌️

⏩ Русскоязычная версия ресурсов

👉 @KodBlog

Одна из самых недооценённых фич в .NET — System.Threading.Channels.

С её помощью можно просто построить асинхронное взаимодействие через сообщения на C#. У Channel есть два API:

- для записи сообщений в канал,

- для асинхронного чтения сообщений из канала.

Можно запустить воркер в фоне, который будет забирать сообщения и передавать их на обработку. На этой основе легко собрать примитивный in-memory message bus (со всеми очевидными ограничениями).

Пример реализации тут

👉 @KodBlog

Как упаковать RPM на Linux через GitLab CI/CD?

В материале детально разбирается разработка службы на .NET Core, конфигурация spec-файла, применение макросов и запуск GitLab Runner внутри Docker. Полезные рекомендации для DevOps по автоматизации билда и контролю версий.

Читать подробнее: https://habr.com/ru/articles/952748/

👉 @KodBlog

Чистим NuGet и освобождаем десятки гигабайт

Со временем NuGet накапливает огромные объёмы кэша:

- http-cache может весить 10+ ГБ

- global-packages легко разрастается до 50 ГБ и больше

Если места на диске не хватает — кэши можно безопасно почистить:

Очистка глобальных пакетов:

dotnet nuget locals global-packages --clear

Очистка http-кэша:

dotnet nuget locals http-cache --clear

Очистка временных файлов:

dotnet nuget locals temp --clear

Полная зачистка всего:

dotnet nuget locals all --clear

После очистки пакеты будут скачаны заново при следующем dotnet restore, но на диске станет намного свободнее.

Проверить текущие кэши можно так:

dotnet nuget locals all --list

👉 @KodBlog

Python vs C#

Два языка — две совершенно разные цепочки выполнения:

C# (.NET Runtime):

🔹Исходный код → Intermediate Language (IL) → сборки (.dll / .exe)
🔹Сборки проверяются и загружаются в .NET Runtime
🔹JIT- или AOT-компилятор переводит IL в машинный код
🔹Мощные инструменты и статическая типизация делают выполнение предсказуемым и быстрым

Python (CPython Runtime):

🔸Исходный код → байткод (кэшируется в .pyc, если возможно)
🔸Система импорта подгружает модули и зависимости во время выполнения
🔸Python Virtual Machine (PVM) интерпретирует байткод “на лету”
🔸Гибкий и динамичный язык, но скорость зависит от накладных расходов интерпретации

Баланс очевиден:

• C# оптимизирован под производительность и безопасность
• Python — под гибкость и скорость итераций

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

👉 @KodBlog

MauiReactor — MVU для .NET MAUI

Открытая библиотека, реализующая паттерн Model View Update для .NET MAUI.

Она упрощает разработку кроссплатформенных приложений, ускоряет hot reload и повышает производительность.

MauiReactor предлагает альтернативу XAML и позволяет описывать интерфейс на C#. Поддерживаются темы, условный рендеринг и интеграция сторонних компонентов.

Подробнее

👉 @KodBlog

Если у нас есть List<T> и IList<T>, то перебор элементов через List<T> выполняется быстрее, чем через IList<T>. Почему так происходит?

[MemoryDiagnoser]
public class Benchmark
{
    private readonly List<int> numbersList = Enumerable.Range(0, 10_000).ToList();
    private readonly IList<int> numbersIList = Enumerable.Range(0, 10_000).ToList();

    [Benchmark(Baseline = true)]
    public int GetSumOfList()
    {
        var sum = 0;
        foreach (var number in numbersList) { sum += number; }
        return sum;
    }

    [Benchmark]
    public int GetSumOfIList()
    {
        var sum = 0;
        foreach (var number in numbersIList) { sum += number; }
        return sum;
    }
}

Результаты:

Метод         Среднее    Ошибка    Ст.откл.   Отн.  Отн.откл.  Память  Отн.память
------------- ---------- --------- ---------- ----- ---------- ------- ----------
GetSumOfList   4.214 μs   0.0836 μs  0.0782 μs  1.00   0.03       -       NA
GetSumOfIList 19.508 μs   0.0459 μs  0.0384 μs  4.63   0.08     40 B      NA

Откуда берутся эти 40 байт?

Когда вызывается List<T>.GetEnumerator() (а это происходит при каждой итерации foreach), возвращается структура под названием Enumerator.

Но при вызове IList<T>.GetEnumerator() возвращается переменная типа IEnumerator, которая содержит упакованную (boxed) версию этого перечислителя.

Вот откуда появляются дополнительные 40 байт аллокации и часть потери производительности.

Виртуальные вызовы методов

Есть и второй фактор.

При вызове IList<T>.GetEnumerator() вызывается виртуальный метод, а это медленнее, чем вызов невиртуального метода.

Причина проста: во время выполнения CLR должно определить, какой конкретный тип реально используется, и уже потом вызвать нужную реализацию метода.

В случае с List<T> этого делать не нужно — тип уже известен, и вызов идёт напрямую, без дополнительной диспетчеризации.

👉 @KodBlog

Получение информации о .NET Runtime в приложении

👉 @KodBlog