🔍 Как работать с массивами в C# без тормозов и без unsafe-кода

В C# каждое обращение к элементу массива проверяется на выход за границы. Это безопасно, но медленно. Разработчики часто решают проблему через unsafe-код с указателями — быстро, но опасно: один неверный индекс, и приложение крашится или получает дыру в безопасности.

Есть третий путь — Span<T>

Span — это структура, которая хранит указатель на данные и их длину. Фишка в том, что это ref struct — она живёт только в стеке и не может попасть в кучу. Благодаря этому компилятор гарантирует: данные переживут span, а значит проверки границ можно убрать.

Например, в быстрой сортровке вместо передачи массива с индексами low/high передаёте span. Код короче, переполнение невозможно, а рекурсивные вызовы работают через срезы:

// Было: опасно, (low + high) может переполниться
void Quicksort(int[] array, int low, int high) {
    int mid = (low + high) / 2;  // 💥 overflow!
    // ...
    Quicksort(array, low, pivot - 1);
    Quicksort(array, pivot + 1, high);
}

// Стало: безопасно и выразительно
void Quicksort(Span<int> span) {
    if (span.Length <= 1) return;
    
    int pivot = Partition(span);
    Quicksort(span[..pivot]);        // левая часть
    Quicksort(span[(pivot + 1)..]);  // правая часть
}

Раньше для передачи части массива в функцию приходилось либо копировать данные, либо таскать массив + offset + length. Span решает это элегантно: создаёте срез array[10..20], передаёте дальше — никакого копирования, полная безопасность типов.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#il_люминатор

✏️ Если вы уже работаете с Claude Code, Cursor или Copilot, этот вебинар будет особенно полезен.

Разберут, как превратить AI из инструмента для отдельных задач в часть инженерного процесса ⬇️

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

Для человека это естественная часть работы. У Claude Code этого контекста по умолчанию нет — только задача и инструкции, которые ему дали.

Поэтому в большой команде недостаточно просто выбрать хорошую модель.

❗️ Нужно ещё объяснить ей, как у вас устроена разработка: какие подходы приняты, что обязательно проверять и по каким правилам принимать решения.

🗓 23 июля в 19:00 МСК поговорим об этом на бесплатном вебинаре с Алексеем Жиряковым — он Executive Director в Сбере, руководит
GenAI Data Platform, и с этой проблемой сталкивался не раз 🔥

Покажет живое демо, разберём, как встроить AI в процесс разработки так, чтобы он реально помогал, а не добавлял ещё один повод для споров на ревью.

🔗 Занять место на вебинаре

🏃‍♀️ Proglib Academy

⚡️ Алгоритму почти 70 лет, а его идея до сих пор используется в системном программировании

В 1957 году Дэвид Уилкс, Дэвид Уилер и Стэнли Гилл описали быстрый способ подсчёта количества установленных битов (popcount).

Вместо проверки каждого бита по отдельности алгоритм постепенно суммирует их:

• сначала попарно;
• затем группами по 4;
• потом по байтам;
• в конце получает итог одним умножением.

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

В .NET для этого есть BitOperations.PopCount(), а подобные алгоритмы до сих пор можно встретить в низкоуровневом системном коде.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#il_люминатор

🤨 Комментарии в коде: писать или удалять всё лишнее?

Один из самых долгих споров среди разработчиков.

❇️ Одни считают, что хороший код не нуждается в комментариях. Если приходится объяснять, что происходит, значит, стоит улучшить имена, структуру или разбить метод.

🅰️ Другие отвечают: комментарии нужны. Но не чтобы пересказывать код, а чтобы объяснить почему он написан именно так. Например, описать сложное бизнес-правило, необычное решение, ограничение внешней системы или оставить ссылку на баг.

А как у вас?

👍 — комментариев минимум, код должен говорить сам за себя.
🔥 — комментарии нужны, если помогают понять неочевидную логику.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#entry_point

🔥 .NET MAUI окончательно переходит на CoreCLR

В .NET 11 Preview 6 для мобильных приложений .NET MAUI остался только один рантайм — CoreCLR. Отдельный путь через Mono для Android, iOS и Mac Catalyst больше недоступен.

🔴 Это тот же рантайм, на котором работают ASP.NET Core, серверные и десктопные приложения .NET. Переход должен сократить различия между платформами и упростить развитие самого рантайма.

По данным команды .NET, на iOS и Mac Catalyst CoreCLR уже обычно быстрее Mono. На Android результаты пока близки: разница по времени запуска и размеру приложения укладывается примерно в 10%.

🔴 В Preview 6 также появились новый CollectionView2 для Windows, версия HybridWebView, совместимая с Native AOT, и восстановление результата MediaPicker после пересоздания Activity на Android.

Переход крупный, поэтому Microsoft просит разработчиков уже сейчас запускать свои MAUI-приложения на Preview 6 и сообщать о регрессиях до ноябрьского релиза.

🔗 Источник

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#async_news

⚠️ Скорость разработки растёт, но вместе с ней появляется новая проблема — кодовая база быстро теряет единый стиль.

Ниже — бесплатный вебинар о том, как этого избежать 🏃‍♀️

🤢 Чем больше разработчиков в команде начинают пользоваться Claude Code, тем заметнее одна проблема: кодовая база перестаёт выглядеть как работа одной команды.

Где-то есть тесты, где-то их забыли. Где-то агент следует архитектуре проекта, где-то предлагает решение, которое с ней не сочетается.

⚠️ И это не проблема Claude Code. Он просто следует тому контексту, который получает от каждого разработчика.

Завтра покажем, как передать AI инженерный контекст команды и не превратить его внедрение в ещё один источник хаоса.

🗓 23 июля, 19:00 МСК
Бесплатно. 60 минут доклада + 30 минут вопросов.

🔗 Занять место на вебинаре и разобраться, почему так происходит

🏃‍♀️ Proglib Academy

🎹 Почему строки в .NET неизменяемы и что такое интернирование

string в .NET нельзя изменить. Любая конкатенация, замена или обрезка создаёт новый объект. Благодаря этому строки безопасно использовать из нескольких потоков, удобно хранить в качестве ключей словаря, а оператор == сравнивает их содержимое.

Но есть и цена: каждое изменение — это новая аллокация. Поэтому для сборки текста в циклах используют StringBuilder, а не +.

🔜 Ещё одна особенность — интернирование строк. CLR хранит пул уникальных строк, поэтому одинаковые строковые литералы обычно ссылаются на один объект. Строки, созданные во время выполнения программы, в этот пул автоматически не попадают, но их можно добавить через string.Intern().

StringBuilder помогает избежать лишних аллокаций, а интернирование стоит использовать только там, где действительно много повторяющихся строк.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#il_люминатор

🦴 Хорошая документация сегодня экономит время не только коллегам, но и AI. Почему она стала важнее, чем кажется, — в посте ниже 👇

😳 Documentation Driven Development звучит как ещё один модный термин. Пока не попробуешь объяснить свой проект AI.

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

🔘 На курсе «ИИ для разработчиков» эту тему разбирает Арсений Харланов. Он покажет, как подготовить документацию и контекст, чтобы агент понимал архитектуру проекта, ограничения и связи между компонентами.

Также разберём, как выбирать модель под задачу: Claude, DeepSeek, Qwen и другие ✏️

Впереди 7 недель работы со своим репозиторием. Вебинары проходят вживую и остаются в записи.

Стартуем 31 августа. До конца июля можно присоединиться по ранней цене, а доступ к материалам останется бессрочным 😀

🔗 Посмотреть, что будет на курсе

🏃‍♀️ Proglib Academy

😎 Новый тип Lock в .NET 9. Пора забыть про object?

В .NET 9 появился специальный тип System.Threading.Lock, созданный именно для синхронизации.

private readonly Lock _sync = new();

public void Add(int x)
{
    lock (_sync)
    {
        _items.Add(x);
    }
}

Синтаксис lock не изменился, но компилятор распознаёт тип Lock и использует его напрямую, без перехода через Monitor. Это делает код более явным и позволяет снизить накладные расходы.

При необходимости блокировку можно взять и без оператора lock:

using (_sync.EnterScope())
{
    _items.Add(x);
}

⚠️ Важно: не приводите Lock к object. В этом случае компилятор предупредит, а оператор lock снова будет работать через старый механизм на базе Monitor.

Для нового кода System.Threading.Lock — рекомендуемый способ реализации взаимного исключения в .NET 9 и новее.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#sharp_view

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#garbage_collector