required свойства: компилятор заставит заполнить поля!

Часто в коде создают объекты, забывая заполнить важные свойства. Ошибка всплывает поздно — где-то в рантайме, когда поле внезапно null.

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

class UserDto
{
    public string Name { get; set; }
    public string Email { get; set; }
}

var user = new UserDto
{
    Name = "Анна"
    // Email забыли…
};

И получаем проблему уже при использовании:

Console.WriteLine(user.Email.Length); // NullReferenceException

В C# 11 можно пометить обязательные свойства как required — и компилятор не даст создать объект без них:

class UserDto
{
    public required string Name { get; init; }
    public required string Email { get; init; }
}

var user = new UserDto
{
    Name = "Анна",
    Email = "anna@mail.com"
};

🔥 required + init = безопасная инициализация: меньше сюрпризов в рантайме, больше контроля на этапе компиляции.

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

❤️ Держите шпаргалку по C#!

На картинке — аккуратная “C# Cheat Sheet”, которая помогает быстро вспомнить основы языка: как писать комментарии, работать с перечислениями enum, использовать циклы for, while и foreach, объявлять и использовать пространства имён, создавать объекты и вызывать методы, а также понимать, как работают делегаты и события в C#.

Сохрани, чтобы код на C# стал проще и понятнее

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

✍️ Hyperpolyglot — сравнение языков в удобных таблицах!

Хочешь быстро понять, чем Python отличается от C#, Rust, C++ или Go. Здесь синтаксис, структура, идиомы и концепции разных языков сравниваются в таблицах, так что можно буквально увидеть, как одна и та же задача решается на разных языках. Это отличный способ прокачать мультиязычное мышление, выбрать язык под задачу или просто пронаблюдать сходства и различия.

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

➡️ C# Ready | #сайт

Как не лепить try/catch вокруг int.Parse()?

Когда число приходит из UI, JSON, CSV или внешней системы — оно может быть пустым, кривым или с пробелами. Если парсить через int.Parse, приходится оборачивать всё в try/catch, и исключения превращаются в “обычный сценарий”.

Вместо этого используй TryParse: он возвращает true/false и не кидает исключения на невалидном вводе:

var age = int.TryParse(input, out var parsed) ? parsed : 0;

А если при невалидном вводе нужно просто выйти — делай guard clause (код читается сверху вниз, без лишних else):

if (!int.TryParse(input, out var age)) return;
SaveAge(age);

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

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

👐 Отличная статья — про то, как CLR создаёт объекты, и почему GC тут вообще “ни при чём”.

В этой статье:
• Поймёшь, как объект выделяется в куче и размечается CLR
• Увидишь, где берутся заголовок, таблица методов и поля объекта
• Разберёшь, что реально ускоряет создание и где ломаются мифы

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

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

List patterns в C# 11: проверяем массивы и списки без if-каши!

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

Раньше это превращалось в проверки Length и индексов:

int[] numbers = { 0, 5, 7, 10 };

if (numbers.Length == 0)
    Console.WriteLine("Пусто");
else if (numbers.Length >= 1 && numbers[0] == 0)
    Console.WriteLine("Начинается с 0");
else if (numbers.Length >= 1 && numbers[^1] == 10)
    Console.WriteLine("Заканчивается на 10");
else if (numbers.Length == 3 && numbers[2] == 10)
    Console.WriteLine("Третий элемент = 10");
else
    Console.WriteLine("Другая форма");

Чем больше условий, тем быстрее это разрастается и становится трудно читать.

В C# 11 появились list patterns, которые позволяют матчить коллекцию прямо по её “форме”:

int[] numbers = { 0, 5, 7, 10 };

var result = numbers switch
{
    [] => "Пусто",
    [0, ..] => "Начинается с 0",
    [.., 10] => "Заканчивается на 10",
    [_, _, 10] => "Третий элемент = 10",
    _ => "Другая форма"
};

Console.WriteLine(result);

Здесь _ означает “любой элемент”, а .. означает “любое количество элементов” между ними.

🔥 В итоге вместо проверок длины и индексов ты пишешь условия так, как думаешь о данных: по форме коллекции.

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

📂 Шпаргалка по основам C#!

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

Сохрани, чтобы держать под рукой основу C# и быстрее ориентироваться при разработке и подготовке к собеседованиям.

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

🤨 LINQPad — интерактивная “песочница” для C#/.NET и запросов к базам данных!

Настольный scratchpad от Джозефа Альбахари: можно быстро писать и запускать C#-скрипты, проверять идеи без создания проектов, а ещё — удобно ходить по данным и джойнить сущности через LINQ или писать обычный SQL.

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

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

Как перестать писать “магические строки” в логах и ошибках?

Часто в логирование и исключения попадают строки вроде "CreateUser" или "UserService" — и как только ты переименовал метод/файл, эти строки не обновились. В итоге логи врут, а поиск по проекту ломается.

Для имён используй nameof() — он безопасен при рефакторинге:

throw new InvalidOperationException(nameof(CreateUser));

А чтобы автоматически подставлять место вызова (метод/файл/строку) — есть caller info атрибуты:

[CallerMemberName] string member = "",
[CallerFilePath] string file = "",
[CallerLineNumber] int line = 0

Теперь ты пишешь просто:

Log.Info("User created");

а в выводе уже будет, откуда это пришло.

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

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

with-выражение: обновляем объект без мутаций и лишнего кода!

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

Раньше приходилось создавать новый объект вручную и копировать остальные свойства:

record User(string Name, int Age, string City);

var user = new User("Анна", 28, "Helsinki");

var updated = new User(
    "Анна Петрова",
    user.Age,
    user.City
);

Console.WriteLine(user);
Console.WriteLine(updated);

Такой код быстро превращается в копипасту: чем больше полей, тем больше риск забыть что-то перенести или случайно перепутать.

С with-выражением можно скопировать объект и изменить только нужные свойства:

record User(string Name, int Age, string City);

var user = new User("Анна", 28, "Helsinki");

var updated = user with { Name = "Анна Петрова" };

Console.WriteLine(user);
Console.WriteLine(updated);

Исходный объект остаётся прежним, а updated — это новая копия с изменённым значением.

🔥 Итог: меньше шаблонного копирования, меньше ошибок и удобный путь к иммутабельному коду.

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