C# *

В следующем месяце выходит очередная версия нашего любимого языка программирования. Чем не повод присесть на кухне с рюмкой чая и обсудить, что не так с современными версиями C#?

В интернетах всегда кто‑то не прав. В этот раз, по моему максимально предвзятому мнению, оказался не прав @bodyawm. Для меня.NET в каждой бочке затычка, поэтому меня бобмануло от использования mono в 2024 году. В этой статье я покажу своё видение того, как максимально канонично и современно писать на.NET для GNU/Linux и SBC (Single‑board computer, aka одноплатник).

Недавно мне повезло пообщаться с Крисом Бэйконом, который написал DotNetAnywhere (альтернативный вариант .NET Runtime), и я остроумно заметил:

… ты, наверное, один из тех немногих, кто создал собственную среду выполнения .NET, и это круто!

если исключить тех, кто на зарплате, т.е. инженеров Microsoft/Mono/Xamarin, их очень немного.

Это — перевод статьи Matt Warren (A History of .NET Runtimes). Дабы не делать повторную публикацию, оставлю as is

Игры большие и трехмерные уже давно радуют глаз реалистичным освещением, мягкими тенями, бликами и прочей осветительной красотой. В двумерных же играх — во главе стола прямые руки художника, который подсветит и затенит где нужно, спрайт за спрайтом, или даже пиксель за пикселем. А если хочется динамики и без художника, и да, в пиксельарте?

Привет, Хабр. Меня зовут Рогатнев Сергей. Я работаю в Контуре ведущим разработчиком уже более 7 лет. За это время я поработал как минимум над десятью разными проектами в разных командах. Это были и проекты с историей на 10 лет, и стартапы, делающие свои первые шаги. Где-то я был всего 2–3 месяца, а где-то задерживался на пару лет. Такой формат работы позволил мне увидеть совершенно разные подходы к работе и написанию кода. За это время я адаптировался к переходам и смене команд, но мой собственный code style практически исчез, потому что нет двух команд с одинаковым стилем.

В этой статье я хочу показать вам примеры таких холиваров, которые я встретил работая над разными C#-проектами.

Здравствуй, Хабр!

Поступая в университет на программиста, я мечтал стать разработчиком игр. Но жизненный путь привёл меня в десктоп на WPF (о чём я, на самом деле, не жалею). А в пет-проекте объединились опыт десктоп-разработчика и стремление писать игры. Так родился пингвинослон Disciples II на Avalonia и WPF.

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

Итак, Бетрезен умирает.

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

Одна из многословных конструкций .NET связана с деталями реализации асинхронности и обросла кучей мифов. Про неё спрашивают на собеседованиях, код-ревью, делают обязательной, добавляя в правила линтера. Это .ConfigureAwait(false), сопровождающий каждый await в коде.

В этой статье я расскажу, зачем нужен ConfigureAwait(false) и как обойтись без него.

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

a -= a *= a;
p[x++] = ++x;

Да кто вообще пишет такой код с невозмутимым видом? Одно дело, когда такое пишешь, пытаясь победить в «Международном Конкурсе запутывания кода на Си» (IOCCC, International Obfuscated C Code Contest), или если хочешь написать головоломку — но в обоих случаях понимаешь, что ты занимаешься чем-то нестандартным. Что, реально есть кто-то, кто пишет a -= a *= a и p[x++] = ++x; и думает про себя «Чёрт возьми, да я пишу действительно классный код!»