День 1041. #ЧтоНовенького
Новый редактор Razor в Visual Studio 2022
С выпуском Visual Studio 2022 версии 17.0.2 вы можете использовать новый редактор Razor.

Преимущества перехода на Language Server Protocol
Новый редактор Razor для проектов ASP.NET Core основан на протоколе языкового сервера (LSP). Это протокол с открытым исходным кодом, который определяет стандартный способ включения функций редактором или IDE. Модель LSP позволила добавить в Razor гораздо больше функций редактирования C# и другие функции для повышения продуктивности, специфичные для Razor.

Что доступно в новом редакторе Razor?
1. В редакторе Razor теперь поддерживается наиболее часто используемый рефакторинг Add missing usings (Добавить недостающие директивы using).

2. Также добавлено несколько функций, специфичных для Razor. Например, Extract block to code behind (Извлечь блок в файл кода) позволяет вам извлечь блок кода в отдельный файл кода, если вы не хотите держать его в одном файле с разметкой. Другие добавленные функции включают:
- Add usings for component (Добавить директивы using для компонента),
- Fully qualify component (Полностью определить компонент),
- Create component (Создать компонент).

2. Улучшена навигация. Одной из наиболее часто используемых функций навигации в Visual Studio является Go to Definition (Перейти к определению). Она помогает быстро перемещаться по файлам и лучше понимать код. Например, нажатие F12 на теге компонента теперь переместит вас прямо в код компонента.

3. Опыт горячей перезагрузки также улучшен, благодаря LSP.

4. В новом редакторе Razor обновлены цвета по умолчанию. Основным отличием является то, что код больше не подсвечивается серым фоном, как это было в предыдущих версиях.

5. Новый редактор обеспечивает улучшенное форматирование, которое лучше справляется с изменениями, помогая коду оставаться визуально согласованным. Поддерживаются более умные дополнения синтаксиса Razor, такие как завершение <text> и автозаполнение. Новый редактор также изменяет способ диагностики, чтобы гарантировать отображение только наиболее важных диагностических сообщений.

6. Razor теперь полностью поддерживает Visual Studio Live Share.

Известные проблемы и дорожная карта
Razor накопил большое количество запросов на добавление функций и исправлений ошибок. Решение этих проблем в устаревшем редакторе Razor было трудным и дорогостоящим. Новый редактор позволит быстрее предоставлять исправления ошибок и новые функции. Есть ещё несколько функциональных пробелов, которые необходимо устранить в следующих выпусках:
- Поддержка сниппетов (с помощью Tab)
- Горячая клавиша «Обернуть в div» - Shift+Alt+W
- Ctrl+щелчок мыши для перехода к определению
- Сворачивание кода в #region
- Встроенное форматирование JavaScript
- Поддержка перетаскивания файлов HTML, CSS и JavaScript
- Улучшения производительности и надёжности
- Поддержка горячей перезагрузки для проектов Blazor Web Assembly при отладке

Следить за дорожной картой вы можете на GitHub.

Если вы обнаружите, что ваша продуктивность в новом редакторе ограничена, вы можете вернуться к предыдущей версии редактора, перейдя в Tools > Options > Text Editor > HTML > Advanced (Инструменты > Параметры > Текстовый редактор > HTML > Дополнительно) и выбрав True в раскрывающемся списке рядом с пунктом Use legacy Razor editor for ASP.NET Core (Использовать устаревший редактор Razor для ASP.NET Core). Имейте в виду, что старый редактор Razor будет иметь ограниченную функциональность и не будет включать улучшения, описанные выше.

Источник: https://devblogs.microsoft.com/visualstudio/introducing-the-new-razor-editor-in-visual-studio-2022/

День 1472. #ВредныеСоветы
11 Способов Усложнить Себе Жизнь в C#. Окончание
1-2, 3-4, 5-6, 7-8

9. Сильно вложенный код
Хотите быстрый и простой способ сделать код труднее для чтения? Вложите условные операторы друг в друга несколько раз, проверяя каждое условие отдельно вместо использования return, && или ?. и ?? для null:

if (building != null)
{
  if (building.Office != null)
  {
    if (building.Office.IsAvailable)
    {
      if (user.CanReserve)
      {
        …
      }
    }
  }
}

Вы могли бы просто написать следующее:

if (building?.Office?.IsAvailable == true 
 && user.CanReserve)
{
  …
}

Заметьте явное сравнение с true, т.к. оператор ?. возвращает bool? (Nullable<bool>), а не bool.

10. Использование интерфейса «один к одному» для класса модели
Когда люди узнают об инверсии зависимостей и моках, они бросаются в крайности, добавляя интерфейс к каждому классу независимо от того, будет ли несколько реализаций интерфейса или необходимо ли будет его мокать.

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

Проблема, если вы создаёте IStudent для ученика, ITeacher для учителя и ILesson для урока. Ни один из этих объектов, скорее всего, не нуждается в моке для тестирования, поскольку в тестах вы можете просто создать экземпляры этих моделей. Полезным может быть интерфейс вроде ISchoolMember для учащихся, учителей и администраторов, когда для всех требуется свойство SchoolID.

11. Размещение регионов внутри методов
Худшее я приберёг напоследок. Не буду стыдить за использование регионов в коде, однако почти всегда их лучше заменить изменением кода. Многим нравится отделять блоки кода регионами, но регион внутри метода должен иметь действительно вескую причину для существования. Помечая блок кода регионом, вы кричите о том, что его надо извлечь в метод:

public ProcessResult Update(ChangeLog changes)
{
  #region Validate
  if (changes == null)
    throw ArgumentException(changes);

  if (…)
    throw …;
  #end region

  #region Log
  logger.Debug(changes);
  …
  #endregion

  …
}

Вместо регионов просто создайте отдельные методы для этих блоков:

public ProcessResult Update(ChangeLog changes)
{
  Validate(changes);
  Log(changes);
  …
}

Источник: https://brendoneus.com/post/Ways-Of-Making-CSharp-Harder/

День 2423. #BestPractices
Вещи, Которые Я Делаю в Каждом Проекте .NET. Продолжение
1-2
3
4-6

7. Не внедряйте IOptions
Проблема с параметрами IOptions в том, что вам нужна зависимость от Microsoft.Extensions. И если вы используете IOptions в других проектах ниже по стеку вызовов, придётся добавлять зависимость во все эти проекты. И тестировать параметр типа IOptions может быть непросто. Кроме того, везде приходится использовать .Value вместо просто имени параметра:

public class MyController(
 IOptions<AppSettings> appSettings)
{
  private readonly AppSettings _appSettings =
   appSettings.Value;
  …
}

Решение - регистрируйте класс IOptions напрямую, так вы получите нужный класс значений в DI контейнере, который уже можно внедрять:

services.Configure<AppSettings>(
 Configuration.GetSection("AppSettings"));
services.AddSingleton(s =>
 s.GetRequiredService<IOptions<AppSettings>>().Value);

…

public class MyController(AppSettings appSettings)
{
 …
}

Если вы хотите, чтобы параметры изменялись без перезагрузки приложения, это тоже будет работать. Регистрируете значения как AddScoped и используйте IOptionsSnapshot<T> вместо IOptions<T>.

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

public ActionResult SendMessage(Message msg)
{
  if(!ModelState.IsValid())
    return View(msg);

  if(emailSender.Send(msg) != Result.OK)
  {
    _logger.Log(…);
    return LocalRedirect("/message/error");
  }
  …
  return LocalRedirect("/message/success");
}

Это не только позволяет быстро найти «счастливый путь», но и избавляет от избыточной вложенности конструкций if.

И некоторые не жёсткие правила, а просто предупредительные сигналы о запахах кода:
- метод длиннее 20 строк,
- класс длиннее 200 строк,
- использование областей (#region).
Это всё сигналы о том, что метод или класс можно разбить на части.

9. Новые файлы решений
Это относительно новая функция. Технически она всё ещё в стадии превью версии, но сейчас довольно стабильна. Если коротко, новые файлы .slnx – это старый добрый XML, они гораздо короче и понятнее. Обновить файл решения можно, просто перейдя в папку решения и выполнив:

dotnet sln migrate

Затем не забудьте удалить старый файл .sln. Он больше не нужен, но утилита его не удаляет.

Окончание следует…

Источник: https://youtu.be/SvcRvolP2NE