Как узнать, какой аргумент пришёл null, без ручных строк?

Обычно в проверках хочется написать “что именно было null”, но если делать это строками, они быстро устаревают после рефакторинга. В итоге кто-то переименовал переменную, а сообщение об ошибке осталось старым.

В C# можно сделать так, чтобы имя выражения подставлялось автоматически — через CallerArgumentExpression. Смотри на параметр:

[CallerArgumentExpression("value")] string? expr = null

Теперь при вызове:

NotNull(user);

если user окажется null, исключение будет ArgumentNullException("user") — без магических строк и без копипасты.

И даже если передать выражение, оно тоже попадёт в текст:

NotNull(cache[key]);

🔥 CallerArgumentExpression — это “бесплатная диагностика”. Меньше ручных сообщений, лучше ошибки, и после переименований всё остаётся корректным автоматически.

➡️ C# Ready | #совет

✍️ Отличная статья — про то, как собрать свою первую 2D-игру на MonoGame!

В этой статье:
• Поймёшь, как устроен игровой цикл: Initialize → LoadContent → Update → Draw;
• Научишься загружать и рисовать текстуры (спрайты) и управлять позициями объектов;
• Разберёшь основы архитектуры 2D-игры на MonoGame и сделаешь первый рабочий прототип

🔊 Продолжай читать на MonoGame

➡️ C# Ready | #статья

ArrayPool<T> в C#: снижаем нагрузку на GC в горячем коде!

Когда в каждом запросе создаётся новый byte[], приложение начинает чаще упираться в сборку мусора. На небольшом трафике это незаметно, но под нагрузкой появляются лишние паузы.

Обычно код выглядит так:

static void Handle(ReadOnlySpan<byte> payload, Stream output)
{
    var buffer = new byte[8192];
    payload.CopyTo(buffer);
    output.Write(buffer, 0, payload.Length);
}

Если такая операция выполняется часто, лучше брать буфер из ArrayPool<byte>.Shared и возвращать его после работы:

using System.Buffers;

static void Handle(ReadOnlySpan<byte> payload, Stream output)
{
    byte[] buffer = ArrayPool<byte>.Shared.Rent(8192);

    try
    {
        payload.CopyTo(buffer);
        output.Write(buffer, 0, payload.Length);
    }
    finally
    {
        ArrayPool<byte>.Shared.Return(buffer, clearArray: true);
    }
}

Важно помнить, что пул может выдать массив больше запрошенного размера, поэтому работай только с нужным диапазоном данных. И всегда возвращай буфер в finally, иначе эффект от пула быстро пропадёт.

🔥 В итоге ты заметно сокращаешь количество аллокаций и делаешь поведение сервиса ровнее под нагрузкой.

➡️ C# Ready | #практика

📂 Напоминалка по HTTP и сетевым протоколам!

Например, HTTP/1.1 использует постоянные соединения, HTTP/2 умеет мультиплексировать запросы в одном TCP-канале, а HTTP/3 работает поверх QUIC и UDP.

На картинке — наглядная эволюция HTTP от первых версий до современных стандартов.

Сохрани, чтобы не забыть!

➡️ C# Ready | #ресурс

Зачем в библиотечном async-коде часто ставят `ConfigureAwait(false)`?

Потому что await по умолчанию пытается “вернуться” в исходный контекст выполнения. В UI это может быть полезно. Но в библиотеке это обычно лишнее и иногда даже вредное.

Частая картина: внутри библиотеки есть await, а дальше никакого UI нет. Но метод всё равно тащит контекст вызывающего кода:

await http.GetStringAsync("/data");

Правильнее — явно сказать: “мне не важно возвращаться в этот контекст”:

await http.GetStringAsync("/data").ConfigureAwait(false);

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

В приложении, где после await ты обновляешь UI, ConfigureAwait(false) может быть неуместен. Это другое правило.

🔥 Меньше привязки к контексту, меньше неожиданностей, и код сразу говорит, что ему не нужен “возврат в UI”.

➡️ C# Ready | #совет

❤️ CodeChef: C# with Beginner DSA — это пошаговый учебный на CodeChef

На нём ты найдёшь roadmap из ~6 курсов: от основ C# и логики до Beginner DSA, а дальше — закрепление через сотни задач по DSA/алгоритмам (под интервью и контесты).

📌 Оставляю ссылочку: codechef.com

➡️ C# Ready | #ресурс

😎 Нашёл полезный материал про ранний этап развития Avalonia!

В этой статье:
• Показаны цели фреймворка и базовые архитектурные решения.
• Разобраны ключевые возможности первой беты для реальных приложений.
• Объясняется, почему экосистема Avalonia стала заметной в .NET-мире.

🔊 Продолжай читать на Habr!

➡️ C# Ready | #статья

HttpClientFactory в ASP,NET Core: убираем таймауты и «умирающие» сокеты!

Частая проблема в сервисах такая: запросов становится больше, а внешнее API начинает отвечать дольше. В какой-то момент появляются случайные таймауты, хотя код «вроде простой».

Обычно это выглядит так:

public async Task<string> LoadOrdersAsync(string url)
{
    using var client = new HttpClient();
    return await client.GetStringAsync(url);
}

Когда HttpClient создаётся на каждый вызов, соединения не переиспользуются нормально. Под нагрузкой это бьёт по стабильности.

В ASP.NET Core лучше один раз настроить клиент через IHttpClientFactory и брать его из DI.

using System.Net.Http;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddHttpClient("orders", client =>
{
    client.BaseAddress = new Uri("https://api.example.com/");
    client.Timeout = TimeSpan.FromSeconds(5);
});

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

builder.Services.AddScoped<OrderService>();

var app = builder.Build();
app.Run();

Теперь сам сервис. Через фабрику получаем именованный клиент и выполняем запрос.

public sealed class OrderService
{
    private readonly IHttpClientFactory _factory;

    public OrderService(IHttpClientFactory factory)
    {
        _factory = factory;
    }

    public async Task<string> LoadOrdersAsync()
    {
        var client = _factory.CreateClient("orders");
        return await client.GetStringAsync("orders/today");
    }
}

Так соединения используются повторно, а поведение под нагрузкой становится заметно ровнее.

🔥 В итоге ты убираешь класс случайных сетевых сбоев и получаешь более предсказуемый прод.

➡️ C# Ready| #практика

FlowchartAI — это бесплатный AI-генератор блок-схем, который из текста или кода автоматически строит диаграмму. Он анализирует твой ввод (описание процесса/алгоритма или код) и превращает его в визуальную блок-схему, которую можно смотреть прямо в браузере без регистрации.

📌 Оставляю ссылочку: flowchartai.org

➡️ C# Ready| #практика

Почему async void почти всегда проблема?

С async Task вызывающий код может сделать await и нормально поймать исключение. С async void такого пути нет.

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

async void допустим в основном для обработчиков событий, где сигнатуру задает сам фреймворк.

static async Task SaveAsync()
{
    await Task.Delay(100);
}

await SaveAsync();

🔥 Итог: в обычном коде используй async Task или async Task<T>. async void оставляй только для событий.

➡️ C# Ready | #совет

📂 Коротко про HTTPS!

HTTPS — это HTTP с защитой. Он шифрует данные между браузером и сервером, поэтому их сложно перехватить и прочитать.

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

Сохрани, чтобы быстро вспоминать, что значит https://

➡️ C# Ready | #ресурс