😎 Полезный разбор типичных ошибок в C#-проектах: перегруженные классы, смешение слоёв и слабая декомпозиция!

В этой статье:
• почему проект быстро становится неуправляемым
• как смешение логики, API и базы усложняет поддержку
• зачем разделять ответственность между слоями

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

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

Почему TryParse() лучше, чем Parse() внутри try/catch?

Когда мы работаем с пользовательским вводом, строкой из файла, query-параметром или данными из внешней системы, невалидное значение — это не что-то неожиданное. Это обычный сценарий, который нужно аккуратно обработать.

Если использовать Parse() и ловить ошибку через try/catch, код выглядит так, будто произошла настоящая авария:

try
{
    var age = int.Parse(input);
    SaveAge(age);
}
catch
{
    ShowError();
}

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

Гораздо понятнее выглядит такой вариант:

if (int.TryParse(input, out var age))
{
    SaveAge(age);
}
else
{
    ShowError();
}

TryParse() сразу показывает намерение:
мы пробуем преобразовать значение и заранее готовы к тому, что оно может быть невалидным.

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

Особенно полезно это при работе с формами, API-запросами, настройками, файлами и любыми данными, которые приходят извне.

🔥 Если ошибка ожидаема — лучше обработать её явно, а не прятать обычную проверку в try/catch.

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

🧐 Разбираем типичные варианты архитектурных ошибок!

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

В статье:
• почему проект быстро становится неуправляемым
• как смешение логики, API и базы усложняет поддержку
• зачем разделять ответственность между слоями

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

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

Почему пустой массив лучше брать через Array.Empty<T>()?

Когда нужно вернуть пустой массив, можно написать так:

return new User[0];

На первый взгляд всё нормально. Мы действительно возвращаем массив без элементов.

Но проблема в том, что каждый раз создаётся новый пустой массив. Хотя смысла в этом нет: пустой массив можно переиспользовать.

Лучше использовать готовый вариант:

return Array.Empty<User>();

Такой код сразу показывает намерение: нам нужен именно пустой массив.

Он не создаёт лишний объект и читается как стандартный способ вернуть “ничего, но без null”.

Это особенно полезно в методах, которые часто вызываются.

🔥 Array.Empty<T>() - маленькая привычка, которая делает код чище и убирает лишние выделения памяти.

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

❤️ Awesome .NET Core — огромная база ресурсов по .NET и ASPNET Core!

Здесь собрано практически всё для .NET-разработчика: библиотеки, шаблоны, инструменты, ORM, статьи, архитектурные решения и полезные сервисы для backend-разработки на .NET Core. Особенно полезно тем, кто работает с ASPNET Core, микросервисами, Docker и современным backend-стеком. Можно быстро найти готовые решения, нужные инструменты и сильно ускорить разработку.

Оставляю ссылочку: GitHub 📱

➡️ C# Ready | #репозиторий

scoped в C#: как не дать ссылке “убежать” наружу!

Иногда при работе со Span<T>, ref и памятью важно не только избежать лишних аллокаций, но и не вернуть наружу ссылку на данные, которые скоро перестанут существовать.

Например, такой код может выглядеть безобидно:

static ReadOnlySpan<char> GetPrefix(ReadOnlySpan<char> text)
{
    return text.Slice(0, 3);
}

Метод принимает участок строки или буфера и возвращает первые 3 символа. Пока данные живут достаточно долго — всё нормально.

Но в более сложном коде можно случайно попытаться сохранить ссылку на временные данные там, где она жить уже не должна. Особенно это важно при работе с Span<T>, stackalloc и ref-параметрами.

В C# для таких случаев есть scoped:

static void PrintPrefix(scoped ReadOnlySpan<char> text)
{
    var prefix = text.Slice(0, 3);

    Console.WriteLine(prefix.ToString());
}

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

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

Особенно полезно это выглядит вместе со stackalloc:

Span<int> numbers = stackalloc int[] { 1, 2, 3, 4, 5 };

Print(numbers);

static void Print(scoped Span<int> values)
{
    foreach (var value in values)
        Console.WriteLine(value);
}

Здесь данные лежат на стеке, и scoped помогает не дать ссылке на них случайно “утечь” наружу.

scoped не делает код быстрее сам по себе. Его задача другая — сделать работу с памятью безопаснее и понятнее для компилятора.

🔥 scoped — способ сказать C#: “эту ссылку можно использовать здесь, но нельзя уносить дальше”.

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

📂 Шпаргалка по безопасности API!

Безопасный API — это не только HTTPS. Нужны authentication, authorization, input validation, rate limiting, audit logs, защита от replay-атак, корректная работа с токенами и ограничение доступа к чувствительным данным.

На картинке — основные практики, которые помогают защитить API от типовых уязвимостей и злоупотреблений.

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

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

😎 Lucidchart — платформа для построения диаграмм, моделирования процессов и визуализации архитектуры!

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

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

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

Почему ContainsKey() перед индексатором часто лишний?

Часто со словарём работают так:

if (users.ContainsKey(id))
{
    var user = users[id];
}

Код выглядит логично: сначала проверили ключ, потом достали значение.

Но в таком варианте словарь ищет ключ два раза.
Первый раз — в ContainsKey(), второй — при обращении через индексатор.

Если нужно сразу получить значение, лучше использовать:

if (users.TryGetValue(id, out var user))
{
    // используем user
}

TryGetValue() за один вызов проверяет ключ и возвращает значение.

🔥 Если тебе нужно значение из словаря, TryGetValue() обычно лучше, чем ContainsKey() + индексатор.

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

👍Камера и AI прямо в MAUI!

В этой статье:
• Получаем кадры с камеры без лишних задержек.
• Запускаем распознавание лиц через MediaPipe Tasks.
• Рисуем оверлеи поверх живого изображения.

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

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