Почему IEnumerable лучше не перечислять несколько раз?

IEnumerable<T> выглядит как обычная коллекция, но это может быть не список.

Это может быть LINQ-запрос, чтение из файла, генератор или результат из базы.

Например:

if (orders.Count() > 0)
{
    foreach (var order in orders)
        Process(order);
}

На первый взгляд код нормальный.

Но Count() может пройти всю последовательность.
А потом foreach пройдёт её ещё раз.

Для маленького массива это не проблема.
Но для тяжёлого источника данных это может быть дорого или даже привести к разным результатам.

Если нужен повторный доступ, лучше явно сохранить данные:

var orderList = orders.ToList();

А если нужен только проход — не делай лишнюю проверку перед foreach.

🔥 IEnumerable<T> — это не всегда коллекция в памяти. Иногда это инструкция, как получить данные.

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

📂 Напоминалка по Rate Limiting!

Например, Token Bucket отлично подходит для API с кратковременными burst-нагрузками, а Leaky Bucket помогает выравнивать поток запросов и защищать сервис от перегрузки.

На картинке — 5 популярных стратегий ограничения запросов, которые стоит знать каждому backend-разработчику.

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

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

Guard: создаём свои проверки аргументов

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

Часто такие проверки пишут прямо внутри метода:

void CreateUser(string email)
{
    if (string.IsNullOrWhiteSpace(email))
        throw new ArgumentException("Email is empty");

    Console.WriteLine($"User created: {email}");
}

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

В C# можно вынести такие проверки в небольшой helper и сделать код чище:

public static class Guard
{
    public static string NotEmpty(string value, string name)
    {
        if (string.IsNullOrWhiteSpace(value))
            throw new ArgumentException($"{name} is empty");

        return value;
    }
}

Теперь проверку можно использовать в любом месте:

void CreateUser(string email)
{
    email = Guard.NotEmpty(email, nameof(email));

    Console.WriteLine($"User created: {email}");
}

Метод NotEmpty сразу делает две вещи: проверяет значение и возвращает его обратно, если всё нормально.

Такой подход особенно удобен, когда в проекте много входных параметров, DTO, команд или сервисных методов. Вместо копирования одинаковых if ты собираешь проверки в одном месте.

Можно сделать вариант ещё удобнее — через extension method:

public static class GuardExtensions
{
    public static string NotEmpty(this string value, string name)
    {
        if (string.IsNullOrWhiteSpace(value))
            throw new ArgumentException($"{name} is empty");

        return value;
    }
}

И тогда код становится короче:

void CreateUser(string email)
{
    email = email.NotEmpty(nameof(email));

    Console.WriteLine($"User created: {email}");
}

Это не сложный паттерн и не отдельная библиотека, а маленький приём, который помогает убрать шум из методов и сделать проверки единообразными.

🔥 Guard — это способ не размазывать одинаковую валидацию по всему проекту.

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

📂 Шпаргалка по LINQ для .NET разработчика!

Например, Where() фильтрует коллекции, Select() преобразует данные, а GroupBy() помогает быстро группировать элементы по ключу.

На картинке — основные LINQ-методы, разбитые по категориям: фильтрация, сортировка, агрегация, группировка, работа с последовательностями и другое.

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

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

Локальная валидация и фильтрация в Minimal API с AddEndpointFilter!

В Minimal API удобно обрабатывать запросы в одной строчке. Но что, если нужно добавить проверку или логирование без лишней обвязки?

С .NET 8 можно использовать AddEndpointFilter — он добавляет поведение *только* к нужному эндпоинту.

Создаём минималку с фильтром на размер файла:

app.MapPost("/upload", UploadFile)
   .AddEndpointFilter(async (context, next) =>
   {
       var file = context.GetArgument<IFormFile>(0);
       if (file.Length > 5_000_000)
           return Results.BadRequest("Файл слишком большой!");
       
       return await next(context); // пропускаем дальше
   });

Теперь сам обработчик остаётся максимально чистым:

static IResult UploadFile(IFormFile file)
{
    // сохраняем, обрабатываем и т.д.
    return Results.Ok("Файл принят!");
}

🔥 Гибкая локальная логика: логирование, авторизация, валидация — без middleware и лишнего кода!

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