День пятьсот семьдесят третий. #ЗаметкиНаПолях
Класс Path
Многие разработчики до сих пор выделяют расширение файла из имени вручную, когда есть встроенный класс Path, который имеет удобные методы, чтобы сделать это за вас. Класс находится в пространстве имен System.IO и содержит множество полезных методов, которые сокращают объем стандартного кода, который вам приходится писать. Многим известны такие методы, как Path.GetFileName и Path.GetExtension, которые делают именно то, что вы ожидаете (извлекают имя файла и расширение соответственно). Рассмотрим несколько менее популярных.

Path.Combine
Этот метод принимает несколько строк пути и объединяет их в один путь. Обычно это делают, чтобы добавить имя файла к каталогу:

directoryPath + "\" + filename

Проблема в том, что вы предполагаете, что разделителем каталогов в системе, в которой работает ваше приложение, является обратный слеш. Но в Unix используется прямой слеш. Это становится серьезной проблемой, поскольку .NET Core позволяет запускать приложения на большом количестве платформ. Path.Combine будет использовать разделитель каталогов, используемый в операционной системе, а также разберётся с избыточными разделителями (удалит дублирующие).

Path.GetTempFileName
Довольно часто бывает необходимо создать временный файл. Вам не важно имя или место хранения, вам просто нужно записать что-то в файл и через некоторое время прочитать оттуда. Можно написать этот код самостоятельно, но это будет утомительно и подвержено ошибкам. Path.GetTempFileName не принимает никаких параметров, он создаёт пустой файл во временном каталоге пользователя, и возвращает вам полный его путь. Поскольку файл находится во временном каталоге пользователя, Windows автоматически удалит его при необходимости, и вам не придётся беспокоиться о засорении системы избыточными файлами.

Path.GetInvalidPathChars / Path.GetInvalidFileNameChars
Path.GetInvalidPathChars и его собрат Path.GetInvalidFileNameChars возвращают массив всех символов, которые недопустимы для пути / имени файла в текущей системе. Я видел много кода, который вручную удаляет некоторые наиболее распространённые недопустимые символы, например, кавычки, но не удаляет другие недопустимые символы, что создаёт бомбу замедленного действия. И, если мы говорим о кросс-платформенности, неверно предполагать, что то, что недопустимо в одной системе, будет недопустимо в другой. Единственная проблема с этими методами в том, что они не позволяют проверить, содержит ли путь недопустимые символы. Из-за этого приходится писать подобные шаблонные методы:

public static bool IsValidPath(string path) {
  if (path == null)
    throw new ArgumentNullException(nameof(path));

  return path.IndexOfAny(Path.GetInvalidPathChars()) < 0;
}

Источник: https://chrisstclair.co.uk/6-lesser-known-features-of-c-net-that-you-should-be-using/

День пятьсот семьдесят пятый. #ЧтоНовенького
Новые функции Visual Studio 2019 v16.8 Preview 2
Интеграция с Git
В некоторых репозиториях содержится более одного решения. Теперь, когда вы откроете такой репозиторий, в обозревателе решений отобразится список решений, из которых вы можете выбрать. См. рис. 1 ниже. По умолчанию вверху располагается пункт «Просмотр папки» (Folder View). Он откроет корневую папку репозитория. Двойной щелчок по одному из решений в списке откроет решение. Кроме того, вы можете использовать кнопку «Переключить представления» (Switch Views) на панели инструментов проводника решений, чтобы вернуться к списку представлений и легко переключаться между решениями в репозитории. Если в вашем репозитории только одно решение, Visual Studio покажет его, а если решений нет, откроется вид просмотра папки.

Повышение продуктивности в .NET
Visual Studio продолжает перенимать крутые фишки Rider'a. На этот раз добавили встроенные подсказки имён параметров перед каждым аргументом в вызовах функций. См. рис. 2 ниже. Чтобы получить доступ к этой функции, нужно включить её в Инструменты > Параметры > Текстовый редактор > C# > Дополнительно (Tools > Options > Text Editor > C# > Advanced) и выбрать «Показывать встроенные подсказки имён параметров» (Display inline parameter name hints).

Кроме того, теперь вы можете извлекать члены из выбранного класса в новый базовый класс с помощью нового вида рефакторинга «Выделить Базовый Класс» (Extract Base Class). Чтобы попробовать это, поместите курсор либо на имя класса, либо на выделенный член. Нажмите Ctrl+., чтобы вызвать меню быстрых действий и рефакторинга. Оттуда выберите «Выделить член(ы) в новый базовый класс» (Pull member(s) up to new base class). Откроется новое диалоговое окно «Выделить Базовый Класс», в котором вы можете указать имя базового класса, место его размещения, выбрать элементы, которые хотите передать в новый базовый класс, и сделать их абстрактными, установив флажок в столбце «Сделать абстрактным» (Make abstract). См. рис. 3 ниже.

Еще одна функция рефакторинга - преобразование typeof в nameof. Использование nameof вместо имени типа позволяет избежать использования рефлексии для извлечения объекта. Поместите курсор на выражение typeof(<QualifiedType>).Name, нажмите Ctrl+. и выберите «Преобразовать 'typeof' в 'nameof'» (Convert 'typeof' to 'nameof'). См. рис. 4 ниже.

Источник: https://devblogs.microsoft.com/visualstudio/visual-studio-2019-v16-8-preview-2/

День пятьсот семьдесят шестой. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
57. Послание в Будущее
В течение многих лет я преподавала и работала бок о бок с программистами. И, возможно, поскольку большинство из них были умными людьми, мне всегда казалось, что они думали так: «Так как проблемы, с которыми они сталкивались, были трудными, то и решения должны быть так же сложны для понимания остальными (возможно, даже для самих себя через несколько месяцев после написания кода).»

Я помню один случай с Джо, студентом моего курса структур данных, который должен был зайти и показать мне, что он написал:
– Спорим, не сможете догадаться, что делает код! – с порога заявил он.
– Ты прав, – согласилась я, не тратя времени на разбор его кода, а думая, как донести до него важную мысль. – Я уверена, что ты много над этим работал. Но мне интересно, не забыл ли ты кое-что важное. Скажи-ка, Джо, у тебя ведь есть младший брат?
– Да, конечно! Фил. Он учится на вашем вводном курсе. Тоже учится программировать! – гордо ответил Джо.
– Замечательно, - сказала я. – Интересно, сможет ли он понять этот код.
– Ни за что! – сказал Джо. – Это сложно!
– А теперь представь себе, – предложила я, – что это настоящий рабочий код, и что через несколько лет Фил устроится на работу и получит задание его изменить. Что ты для него сделал?

Джо просто уставился на меня и моргал.

– Мы знаем, что Фил очень умный, верно? – Джо кивнул. – И я очень не люблю это говорить, но я тоже довольно умная! – Джо усмехнулся. – Так что, если я не могу быстро понять, что ты здесь сделал, то и твой очень умный младший брат, вероятно, будет ломать голову над этим.

Мне показалось, что Джо несколько иначе стал смотреть на свой код.

– Давай поступим так, – предложила я максимально дружелюбно. - Думай о каждой строке кода, которую ты пишешь, как о послании для кого-то в будущем. Кого-то, кто может оказаться твоим младшим братом. Представь, что ты объясняешь этому умному человеку, как решить эту трудную задачу.
Как ты себе это представляешь? Наверняка, что умный программист в будущем увидит твой код и скажет: «Вау! Это круто! Я прекрасно понимаю, что здесь происходит, и меня поражает, какой это элегантный и красивый фрагмент кода. Я хочу показать остальным в моей команде. Это шедевр!»
Джо, как ты думаешь, сможешь ли ты написать код, который решает эту сложную проблему, но будет настолько красив, что будет петь? Да, как навязчивая мелодия. Я думаю, что любой, кто может придумать очень сложное решение, как, например, твоё, также мог бы написать что-нибудь красивое. Хм… А может мне стоит ставить оценки за красоту? Что скажешь?

Джо взял свою работу и посмотрел на меня с легкой улыбкой:
– Я понял, профессор, я собираюсь сделать мир лучше для Фила. Спасибо.

Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Linda Rising.

День пятьсот семьдесят седьмой. #Оффтоп #ЗадачиНаСобеседовании
В пандан ко вчерашнему посту про простоту и понятность решений, сегодня задачка на выходные.

Прямоугольная любовь
Команда учёных-любителей создала новый сайт знакомств. Отличительной особенностью его является инновационный способ представления профилей людей в виде прямоугольников на плоскости. Чем больше пересечение прямоугольников, тем больше у них шансов на успешные отношения.
Команде нужна помощь в написании алгоритма, находящего пересечение прямоугольников. Как показано на картинке ниже, стороны прямоугольников параллельны осям x и y.

Метод должен получать на вход 2 объекта класса Rectangle, имеющего свойства:
- координаты левой нижней точки
- длина
- ширина
На выходе должен получаться такой же объект Rectangle, представляющий собой пересечение.

Особенность этой задачи не в оптимизации по времени или памяти, а в получении результата, который работает, а главное легко читается. Многие могут описать решение на высоком уровне, но спотыкаются, когда вникают в детали. Поэтому:
1. Продумайте и нарисуйте все возможные варианты.
2. Используйте конкретные и информативные имена переменных.

Как обычно, приглашаю всех предлагать варианты решения в чате.

День пятьсот семьдесят восьмой. #Оффтоп
Чтобы скрасить последнее воскресенье лета, предлагаю вам небольшой ютубовский плейлист (он в настоящее время пополняется) о производительности LINQ. Немного… хотя нет, много байтодрочерства и микрооптимизаций, но всё равно довольно интересное объяснение внутреннего устройства популярного механизма C#, а также советы, чего следует избегать и как в отдельных случаях можно повысить его производительность, переопределив стандартные методы.

К сожалению, видео на английском, а автор поляк, поэтому качество английского (да и его речи вообще) оставляет желать лучшего. Но, несмотря на это, если вам интересны милли- и наносекунды, бенчмарк и вотэтовсё, наслаждайтесь.

C# LINQ Performance

День пятьсот семьдесят девятый. #Оффтоп #ЗадачиНаСобеседовании
Ответ на субботнюю задачу

Задача не очень сложная, главное грамотно разбить её на части.
Мы можем рассматривать «горизонтальное» пересечение прямоугольников (по оси x) отдельно от пересечения «по вертикали» (по оси y). Например, мы рассмотрим ширину прямоугольников как отрезки на одномерной числовой прямой x. Какие возможные случаи расположения этих отрезков?
1) Пересекаются частично
2) Один отрезок полностью содержится в другом
3) Не пересекаются
4) "Касаются" в одной точке
См. рисунок ниже.

Если рассматривать первые два варианта, можно заметить, что пересечение отрезков всегда начинается в точке старта с бОльшей координатой. Поэтому чтобы найти начало пересечения, выбираем максимум из значений S1 и S2. Аналогично конец пересечения будет в меньшей из точек E1 и E2.
Таким образом, найдя начало и конец отрезка, нам остаётся только узнать его длину. Если она положительная (конечная точка больше начальной), то пересечение есть, отрицательная – отрезки не пересекаются, нулевая – отрезки касаются.

static Segment Overlap(Segment s1, Segment s2)
{
  // начальная точка (максимальная из начальных)
  double start = Math.Max(s1.StartPoint, s2.StartPoint);
  // конечная точка (минимальная из конечных)
  double end = Math.Min(s1.StartPoint + s1.Length, s2.StartPoint + s2.Length);

  // отрезки не пересекаются
  if (start > end)
    return null;

  return new Segment(start, end - start);
}

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

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

public static Rectangle RectangularOverlap(Rectangle r1, Rectangle r2)
{
  // пересечение по оси x
  Segment xOverlap = Overlap(
    new Segment(r1.StartPoint.X, r1.Width),
    new Segment(r2.StartPoint.X, r2.Width));
  // пересечение по оси у
  Segment yOverlap = Overlap(
    new Segment(r1.StartPoint.Y, r1.Height),
    new Segment(r2.StartPoint.Y, r2.Height));

  if (xOverlap?.Length >= 0 && yOverlap?.Length >= 0)
    return new Rectangle(
        new Point(xOverlap.StartPoint, yOverlap.StartPoint),
          xOverlap.Length,
          yOverlap.Length
        );

  // не пересекаются
  return null;
}

PS: я в коде использовал новый тип записи. Вот весь код объявления:

public record Point(double X, double Y);
public record Segment(double StartPoint, double Length);
public record Rectangle(Point StartPoint, double Width, double Height);

Можно использовать класс или структуру, но их описание со свойствами и конструкторами гораздо длиннее)))
PPS: да, в коде не хватает валидации исходных данных.
PPPS: строго говоря, решение можно слегка оптимизировать, не проверяя пересечение по y, если нет пересечения по x.

Источник: https://www.interviewcake.com/question/csharp/rectangular-love

День пятьсот восьмидесятый.
Вот и осень. С днём знаний всех причастных.

В юбилейный пятисотый день я рассказал об идее создания опенсорс проекта и спросил у вас, интересно ли вам в нём поучаствовать. Тогда я рассчитывал, что к осени я «разберусь» с экзаменом по ASP.NET MVC, но вот уж осень, а до экзамена мне ещё, как до Китая р… в общем, сейчас не об этом. Откликнулись очень многие, поэтому, как обещал, выкладываю подробности проекта.

Итак.

Часто у изучающих программирование вообще и С# и .NET в частности возникают подобные вопросы:
- «Я изучил основы (прочитал книгу XXX, посмотрел курс YYY), что дальше, куда копать?»
- «Стоит ли читать книгу A (проходить курс B)?»
- «Почему все ругают сайт M?»
Кроме того, меня уже не раз просили как-нибудь систематизировать посты на канале.

Так вот, у меня возникла идея проекта (веб-сайта) с рабочим названием «Путь разработчика». На сайте визуально будет представлен путь от стажёра до… не буду говорить сеньора... до профессионала в определённой области. На этом пути по шагам будут расписаны темы, обязательные для изучения, желательные, либо сторонние, но тоже полезные. Для каждой темы будет приведено краткое описание (если возможно) и набор источников, по которым её можно изучить, в виде ссылок: книги, статьи, руководства, курсы, видео и т.п. Помимо этого система позволит пользователям оценить качество каждого источника, оставить комментарий, а более «продвинутым» предложить свои источники.

Короче говоря, я хочу создать что-то похожее на довольно широко известную и, к сожалению безвременно покинувшую нас (но интернет всё помнит) «Карту знаний .NET Web программиста». А визуально это представить в виде интерактивного дерева, подобно проекту от Moien Tajik.

Можно начать с пути для ASP.NET, но расширять, конечно, можно до бесконечности, как по технологиям семейства .NET, так и в другие технологии, языки и системы. Кроме того, поскольку подавляющее большинство доступной информации на английском, есть идея сделать сайт мультиязычным с английским в качестве основного.

Важные замечания
1) Проект учебный, поэтому будет создаваться на .NET5, C#9 и Blazor (детали ещё обсудим) с целью изучения новых технологий на практике.
2) Проект учебный, "по обмену премудростями", читай некоммерческий (по крайней мере пока). Поэтому участие добровольное и бесплатное (в обе стороны). Зачем вам это может быть нужно, я описал в первоначальном посте.

Остальные детали можно обсудить. Но поскольку заинтересовавшихся было много, предлагаю делать это не в чате, а в более долговременном хранилище информации. Я не нашёл ничего лучше, чем GitHub (надеюсь, аккаунт есть у подавляющего большинства из вас). Подробное описание проекта будет здесь https://github.com/sbzenenko/DeveloperPathAbout/
Обсуждение предлагаю вести в Issues. Там уже открыто несколько тем. Если ваш вопрос не относится ни к одной из них, создавайте новую.

Жду ваших отзывов.

День пятьсот восемьдесят первый. #ЧтоНовенького
Полутип
Тип Half – это 16-битное число с плавающей точкой (эквивалент binary16 в спецификации IEEE 754). То есть это половина от float, и может представлять значения в диапазоне ±65504. Один из основных вариантов использования типа Half - экономия места для хранения, когда вычисленный результат не нужно сохранять с полной точностью. Многие системы уже используют преимущества типа Half: машинное обучение, графические карты, новейшие процессоры, нативные библиотеки SIMD и т.д.

16 бит в типе Half делятся на:
- Знак: 1 бит
- Экспонента: 5 бит
- Значимые биты: 10 бит (с 1 неявным битом, который не хранится)
Несмотря на то, что значение состоит из 10 бит, общая точность на самом деле составляет 11 бит. Предполагается, что формат имеет неявный начальный бит, равный 1 (если в поле экспоненты не все нули, в противном случае 0).

Вот так в формате Half представляется число 1:

0 01111 0000000000 = 1

- Ведущий бит (знак) равен 0 – положительное число.
- Биты экспоненты равны 01111 или 15 в десятичной системе. Биты экспоненты не представляют экспоненту напрямую. Вместо этого определяется смещение экспоненты, которое позволяет формату представлять как положительные, так и отрицательные значения экспоненты. Для типа Half смещение экспоненты равно 15. Истинная экспонента получается вычитанием:

e = 01111(или 15) - 15(смещение) = 0.

- Значение равно 0000000000. Оно представляет собой числитель дроби, в знаменателе которой 1024 (2^10). В нашем случае числитель равен 0. Но, если бы значение было, например, 0000011010 (26 в десятичной системе), то дробь представляла бы собой 26/1024 или 0,025390625.
- Наконец, поскольку биты экспоненты (01111) не все равны 0, у нас есть неявный ведущий бит 1.

Итого:

0 01111 0000000000 = 2^0 * (1 + 0/1024) = 1

Общая формула значения Half:

-1^(знак) * 2^(экспонента - 15) * (неявный бит + (значение/1024))

Особый случай для экспоненты 00000:

-1^(знак) * 2^(-14) * (0 + (значение/1024))

Примеры
Наименьшее положительное значение

0 00000 0000000001 = -1^(0)*2^(-14)*(0 + 1/1024) ≈ 0,000000059604645

Наибольшее число

0 11110 1111111111 = -1^(0)*2^(15)*(1+1023/1024) ≈ 65504

"Бесконечность"

1 11111 0000000000 = -Бесконечность
0 11111 0000000000 = +Бесконечность

Особенность формата в том, что он определяет как положительный, так и отрицательный 0:

1 00000 0000000000 = -0
0 00000 0000000000 = +0

Преобразования в/из float/double

float f = (float)half;
Half h = (Half)floatValue;

Любое значение Half может быть представлено как float/double без потери точности. Однако обратное неверно.

В .NET 5.0 тип Half - это прежде всего промежуточный тип, для которого не определены арифметические операторы. Он поддерживает только парсинг, форматирование и сравнение. Для всех арифметических операций потребуется явное преобразование в float/double. В будущих версиях будет рассмотрено добавление арифметических операторов непосредственно в Half и использование его в вычислениях напрямую.

Источник: https://devblogs.microsoft.com/dotnet/introducing-the-half-type/

День пятьсот восемьдесят второй. #TipsAndTricks
Повышаем продуктивность в Visual Studio.
33. Фильтр Решения
В крупном корпоративном приложении у вас может быть и 20, и 30 проектов, и иногда вам не нужно загружать их все. В Visual Studio 2019 вы можете выгрузить эти проекты, затем щелкнуть правой кнопкой мыши на решении, и выбрать пункт «Сохранить как Фильтр Решения» (Save as Solution Filter). Укажите имя, и сохраните файл. Если вы откроете файл фильтра решения, студия не загрузит выгруженные проекты.

34. Повторное использование кода
Допустим, вы хотите повторно использовать фрагмент кода. Это легко сделать, выбрав соответствующий фрагмент, и сохранить его на панели инструментов (Toolbox). Чтобы открыть Toolbox, нажмите Ctrl+Alt+X, выберите фрагмент кода и просто перетащите его туда.

Источник: https://devsuhas.com/2020/01/19/visual-studio-2019-tips-and-tricks/

День пятьсот восемьдесят третий. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
58. Тестировщики - твои друзья
Их отдел может называться Контролем Качества (Quality Control) или Обеспечением Качества (Quality Assurance), но многие программисты называют их занозой в ж…. Обычно программисты враждуют с людьми, которые тестируют их программы. «Они слишком придираются» и «Они хотят, чтобы всё было идеально» - частые жалобы. Звучит знакомо?

Не знаю почему, но у меня всегда был другой взгляд на тестировщиков. Может быть, потому что «тестером» на моей первой работе была секретарша. Маргарет была очень приятной женщиной, которая поддерживала работу офиса и пыталась научить пару молодых программистов, как вести себя профессионально перед клиентами. У неё также был дар находить за считанные минуты любую ошибку, даже самую неочевидную.

Тогда я работал над программой, написанной бухгалтером, который думал, что он программист. Стоит ли говорить, что с программой были серьёзные проблемы. Когда я думал, что исправил кусок программы, Маргарет пыталась его использовать, и, чаще всего, он отказывал каким-то новым образом после всего лишь пары нажатий клавиш. Временами это расстраивало и бесило, но она была таким приятным человеком, что я и не думал винить её за то, что она выставляла меня в плохом свете. В конце концов, настал день, когда Маргарет смогла запустить программу, забить в неё документ, распечатать его и закрыть. Я был в восторге. Более того, когда мы установили программу на машину нашего клиента, всё заработало. Клиенты никогда не сталкивались с проблемами, потому что Маргарет помогала мне находить и исправлять их.

Вот почему тестировщики - ваши друзья. Вы можете думать, что тестировщики пытаются унизить вас, сообщая о незначительных проблемах. Но когда клиенты в восторге от того, что их не беспокоили все те «мелочи», которые QA заставил вас исправить, тогда вы в глазах клиентов выглядите отлично.

Представьте себе: вы тестируете утилиту, которая использует «новейшие алгоритмы искусственного интеллекта» для поиска и устранения проблем состояния гонки в многопоточных приложениях. Вы запускаете её и сразу замечаете, что на заставке неправильно написано слово «интеллект». Немного неприятно, но это всего лишь опечатка, правда? Затем вы видите, что на экране настройки используются флажки там, где должны быть переключатели, а некоторые сочетания клавиш не работают. Понятно, что всё это не имеет большого значения, но по мере того, как ошибки накапливаются, вы начинаете задумываться о квалификации программистов. Если они не могут сделать простые вещи правильно, каковы шансы, что их программа действительно сможет найти и исправить что-то сложное?

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

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

Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Burk Hufnagel.

День пятьсот восемьдесят четвёртый. #ЗаметкиНаПолях
IAsyncDisposable
Интерфейс IDisposable существует с .NET Framework 1.0 и даёт нам возможность освобождать занятые ресурсы.

using (var disposable = new Disposable()) { … }

У IDisposable есть недостаток, который стал более очевидным с появлением Task. Освобождение ресурсов происходит синхронно и может блокировать потоки. Хуже того, неправильная утилизация асинхронного ресурса может привести к взаимным блокировкам.

IAsyncDisposable
В .NET Core 3 появился интерфейс IAsyncDisposable, который позволяет освобождать асинхронные ресурсы в методе DisposeAsync, возвращающем ValueTask:

public interface IAsyncDisposable {
  ValueTask DisposeAsync();
}

Заметьте, что IDisposable и IAsyncDisposable могут быть реализованы независимо друг от друга. Скорее всего, IAsyncDisposable не реализует IDisposable, потому что создатели не захотели создавать у разработчиков ложное впечатление, что по умолчанию во всех случаях есть синхронный вариант.

Использование
Вот простой пример использования новой конструкции await using с IAsyncDisposable. Сначала напишем класс, реализующий интерфейс:

public class HotGarbage : IAsyncDisposable {
  public async ValueTask DisposeAsync() {
    Console.WriteLine("Чем так пахнет?");
    await Task.Delay(TimeSpan.FromSeconds(3));
    Console.WriteLine("Выкидываем мусор");
  }
  public void Look() => Console.WriteLine("Хмм..."); 
}

Надо заметить, что раз класс реализует IAsyncDisposable, то, вероятно, он имеет зависимости, требующие асинхронного удаления. Использование:

static async Task Main(string[] args) {
  async Task Run() {
    await using var hotGarbage = new HotGarbage();
    hotGarbage.Look();                
  }

  await Run();
}

Мы используем локальную функцию внутри метода Main. Ключевые слова await using полезны, чтобы уменьшить количество скобок в коде и снизить вероятность ошибки при рефакторинге. Запустив код, мы видим результаты нашего асинхронного удаления:

Хмм...
Чем так пахнет?
Выкидываем мусор

Итого
Интерфейс IAsyncDisposable должен упростить написание библиотек, которые имеют дело с операциями ввода-вывода. Авторы библиотек доступа к базам данных, обработки изображений и интернет-протоколов должны иметь возможность изящно избавляться от управляемых ресурсов, не опасаясь взаимных блокировок. Мы, как потребители библиотек, получаем приятный синтаксический сахар в виде конструкции await using, что ещё больше упрощает код.

Источник: https://khalidabuhakmeh.com/iasyncdisposable-dispose-resources-asynchronously

День пятьсот восемьдесят пятый. #ЧтоНовенького
Управляем Уровнем Анализа Кода в .NET5
В последних версиях .NET добавлены новые анализаторы кода, позволяющие вам автоматически находить скрытые недочёты в коде, которые могут приводить к ошибкам. При этом в анализаторы кода редко добавлялись новые предупреждения, т.к. это технически является критическим изменением для пользователей, установивших предупреждения как ошибки.

В .NET5 в компилятор C# добавлена настройка AnalysisLevel, позволяющая безопасно добавлять новые предупреждения в анализаторы. Уровень анализа по умолчанию для всех проектов на .NET5, будет установлен на 5. Это означает, что будут показываться новые предупреждения, введённые в .NET5.

Для предыдущих версий платформы уровень по умолчанию установлен на 4, что не мешает вам самостоятельно установить его в значение от 0 до 3.
Вот, как это сделать:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <AnalysisLevel>5</AnalysisLevel>
  </PropertyGroup>
</Project>

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

<AnalysisLevel>latest</AnalysisLevel>

Обратите внимание, что при этом результаты анализа могут различаться на разных машинах в зависимости от доступного на машине SDK и уровня анализа, который он предлагает.

Наконец, можно задать значение none, означающее запрет новых предупреждений. В этом режиме вы не получите ни расширенного анализа, ни новых предупреждений компилятора. Это полезно, если вы переходите на более новую платформу, и пока не готовы разбираться с новыми предупреждениями.

Вот некоторые новые предупреждения на уровне анализа 5:
CA1416 – Предупреждение: Код работает не на всех платформах
CA2013 – Предупреждение: Не используйте ReferenceEquals с типами-значениями
CA2200 – Предупреждение: Выбрасывайте исходное исключение, чтобы сохранить стек вызовов
CS0185 – Ошибка: lock недопустим на нессылочных типах
CS7023 – Ошибка: Недопустимо использовать as или is со статическими типами
CS8073 – Предупреждение: Выражение всегда ложь или истина

Источник: https://devblogs.microsoft.com/dotnet/automatically-find-latent-bugs-in-your-code-with-net-5/

День пятьсот восемьдесят шестой. #TipsAndTricks
Как Обеспечить Одинаковый Стиль Кодирования в Ваших Проектах
У каждой компании/команды свой стиль программирования. Это касается именования, пробелов или использования функций языка. Вы используете табы или пробелы и сколько пробелов? Вы используете PascalCase или camelCase? Вы ставите нижнее подчёркивание перед именами полей? Вы используете var всегда или только когда тип очевиден? И ещё несколько вопросов подобного типа…

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

Файл .editorconfig
EditorConfig помогает разработчикам определять и поддерживать согласованные стили кодирования для разных редакторов и IDE. Проект EditorConfig – это специальным образом отформатированный файл с определениями стилей кодирования и набор плагинов для текстовых редакторов, которые позволяют редакторам читать этот файл и применять определённые в нём стили. Файлы EditorConfig легко читаемы и прекрасно работают с системами контроля версий.

EditorConfig поддерживается Visual Studio и JetBrains Rider изначально, а в Visual Studio Code через плагин.

Как это работает?
IDE ищет файл с именем .editorconfig в корне вашего репозитория. Файл содержит инструкции для разных файлов проекта на основе шаблона подстановки. Есть глобальные инструкции, такие как indent_style или indent_size, и специальные инструкции для C#, такие как dotnet_sort_system_directives_first. Вот пример:

# Глобальные настройки
[*]
indent_style = space

# Файлы кода
[*.{cs,csx,vb,vbx}]]
indent_size = 4
insert_final_newline = true
charset = utf-8-bom

# Файлы проекта
[*.{csproj,vbproj,vcxproj,vcxproj.filters,proj,projitems,shproj}]
indent_size = 2

# Специальные директивы для .NET
[*.{cs,vb}]
dotnet_sort_system_directives_first = true
dotnet_style_require_accessibility_modifiers = always:warning

# …

Файл .editorconfig помещается в репозиторий, поэтому каждый участник может использовать его для написания кода, соответствующего стилю кодирования. Кроме того, Visual Studio покажет меню быстрых правок и редактирования с советами по изменению кода в соответствии со стилем кодирования, определённым в файле конфигурации.

Создать файл .editorconfig можно и в проводнике Windows, но Visual Studio может создать его для вас. Нажмите правой кнопкой на решение, выберите «Добавить Новый Элемент…» (Add New Item…), в появившемся окне найдите editorconfig File (.NET) на вкладке Общие (General).

Вот несколько полезных ресурсов про .editorconfig в .NET:
- пример файла из проекта ProjectSystem
- документация по правилам .NET

Источник: https://www.meziantou.net/enforce-dotnet-code-style-in-ci-with-dotnet-format.htm