☕️ Guru99 C# — это крутой онлайн-ресурс для самостоятельного изучения языка!

На нём собраны структурированные уроки, которые охватывают как базовые, так и продвинутые темы — от переменных и циклов до ООП, работы с файлами и созданием оконных приложений.

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

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

Читаем большой файл построчно — когда лог огромный, а память не резиновая!

Иногда нужно обработать большой лог или CSV на десятки/сотни мегабайт. Если читать его целиком через ReadAllLines(), файл сначала полностью грузится в память — это лишние аллокации и давление на GC.

Для таких случаев в C# есть File.ReadLines() — он читает файл лениво, отдавая строки по мере чтения.

Подключим нужные пространства имён:

using System;
using System.IO;

Зададим путь к файлу:

string path = @"C:\Logs\app.log";

Пройдёмся по файлу построчно и посчитаем ошибки:

int errors = 0;

foreach (var line in File.ReadLines(path))
{
    if (line.Contains("ERROR"))
        errors++;
}

Console.WriteLine($"Найдено ошибок: {errors}");

🔥 ReadLines() идеально подходит для больших файлов: не загружает всё в память, обрабатывает “на лету” и помогает избежать лишних аллокаций.

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

🤫 Шпаргалка: как работает HTTPS!

На картинке — простая схема, которая показывает, как браузер и сервер создают безопасное соединение: сначала проверяют сертификат через CA, затем обмениваются ключами и выбирают шифры, а после поднимают зашифрованный туннель для передачи данных с сеансовым ключом.

Сохрани, чтобы быстро освежить в голове TLS-рукопожатие и легко объяснить HTTPS на собесе или друзьям!

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

💅 Tutorials Teacher — сайт для начинающих в C#

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

📌 Ссылочка: tutorialsteacher.com

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

Как писать SQL / JSON с интерполяцией без +, \n и экранирования?

Когда в коде появляются большие SQL или JSON, обычные строки быстро превращаются в кашу: конкатенации, \n, кавычки, сложно читать и ещё сложнее править.

В C# 11 появились raw-строки ("""), которые позволяют писать многострочный текст “как есть”:

var sql = """
SELECT * FROM Users
""";

Но что делать, если в тексте нужны переменные?

Для этого используются raw-строки с интерполяцией — $$""" и {{ }}:

var sql = $$"""
FROM {{table}}
WHERE Name = '{{name}}'
""";

Количество $ определяет, сколько { нужно для вставки значения — это позволяет без боли писать JSON, SQL и шаблоны с фигурными скобками внутри.

🔥 raw-строки с интерполяцией — лучший способ хранить большие тексты в коде.

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

❤️ Refactoring.Guru — это образовательный сайт о рефакторинге, паттернах проектирования и принципах SOLID!

На нём вы найдёте каталог code smells (запахов кода) и техник рефакторинга, а также разбор 22 классических паттернов с понятными объяснениями и примерами. Плюс — книги и материалы для системного изучения темы.

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

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

CallerArgumentExpression: показываем точное выражение в ошибке без ручных строк!

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

Раньше приходилось писать сообщения руками, чтобы понять причину падения:

static void Ensure(bool condition, string message)
{
    if (!condition)
        throw new ArgumentException(message);
}

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

И вот как это выглядит на реальном вызове:

var user = "Анна";
var age = -1;

Ensure(!string.IsNullOrWhiteSpace(user), $"Некорректный user: '{user}'");
Ensure(age > 0, $"Некорректный age: {age}");

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

В C# 10 появился CallerArgumentExpression — он умеет получать исходный текст выражения, которое передали в метод:

using System.Runtime.CompilerServices;

static void Ensure(bool condition, string? message = null,
    [CallerArgumentExpression("condition")] string? expr = null)
{
    if (!condition)
        throw new ArgumentException(message ?? $"Проверка не прошла: {expr}");
}

А вызов теперь можно сделать коротким, без ручных строк:

var user = "Анна";
var age = -1;

Ensure(!string.IsNullOrWhiteSpace(user));
Ensure(age > 0);

Если условие провалится, сообщение получится информативным автоматически, например “Проверка не прошла: age > 0”.

🔥 Проверки становятся короче, а сообщения об ошибках — намного полезнее без копипасты.

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

❓ А у вас в проекте “unsafe” когда-нибудь появлялся незаметно?

В C# обсуждают идею caller-unsafe: опасный API помечается так, что вызвать его можно только из кода в unsafe.

Почему это важно: сейчас метод может быть объявлен unsafe, но это не всегда означает, что вызывающий код тоже обязан быть unsafe. Из-за этого небезопасные места иногда прячутся “между строк” и хуже ловятся на ревью.

Если фичу примут, контракт станет честнее: хочешь вызвать такой метод — явно отмечай место вызова как unsafe (осознанно).

Обсуждение: dotnet/csharplang

➡️ C# Ready | #новость

Почему ??= читается лучше, чем if (x == null)?

Самая частая “мелкая боль” в C# — ленивые дефолты: “если ещё не задано — создай”. Из-за этого в коде растут одинаковые проверки null, которые не добавляют смысла и мешают читать логику.

Оператор ??= делает ровно то же самое, но прямо выражает намерение:

user ??= new User();

Это эквивалентно:

if (user == null)
    user = new User();

Особенно полезно, когда значение может прийти из разных мест (DI, конфиг, кеш), и ты просто хочешь гарантировать дефолт без лишнего ветвления.

🔥??= — дешёвый способ убрать шум, снизить шанс “забыл присвоить” и сделать код читаемым

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