Nik Faraday

Сказано же по русски, что только выражения могут быть в тернарном операторе.
Операция присваивания выражением не является.

И вообще за подобный код, как у вас в примере, по рукам бить надо.
Вот это лучше будет гораздо:
countOfIteration = Math.Min(width, height);
А если так сильно хочется тернарник, то вот:

countOfIteration = width > height
  ? height
  : width;

Сначала корневую библиотеку, потом плагин. Относительно как подключать конфигурацию, обычно в документации к такому плагину есть описание и нет однозначного ответа, так как это зависит как написан плагин.
Стили: сначала общие потом твои. Зависимость от того, что ты подключаешь допустим, если ты используешь bootstrap сначала его, потом в сети нашел какую-то тему для bootstrap, то ее уже после основной. Все что ниже перезаписывает верхние грубо говоря.

У вас очень логичный вопрос на счет сеттера: сеттер полностью уничтожает задумку с инкапсуляцией. Правильно это называется "семантическое нарушение инкапсуляции" — то есть как-бы мы инкапсулировали, но по факту назад открыли прямую запись в свойство напрямую. Все доводы "ну мы можем в сеттере валидировать" не корректны

Правильным способом будет не использовать сеттеры. Вот моя статья на эту тему:
https://habr.com/ru/post/469323/

Более подробно: каждый класс нужно проектирвовать так, чтобы данные внутри были максимально связаны. Например каждый метод работать должен в хорошем случае с максимальным числом полей класса, тогда у него высокий cohesion... В тоже время снаружи наужно работать с максимальн омалым числом метода, тогда будет низкая связанность (coupling). Это пара принципов из GRASP.
Когда вы делаете сеттеры и геттеры, то у вас данные внутри между собой почти никак не взаимодействут: с геттером работают снаружи, с сеттером работаю снаружи — весь класс нараспашку, а в нем в 100% случаев появляются данные, которые вместе не должны находиться и никак не связаны — анрушена и абстракция и инвариант и много чего еще...

Про инвариант отдельно: например есть платеж, у него есть значение, с которым платеж инициирвоан (initValue), есть значение холда (holdAmount) и есть значение чарджа на списание (chargeAmount)
Когда вы работаете с платежом, контролируя ивнариант в самом классе, то ваш каждый метод првоеряет др значения и позволяет перейти к др состоянию... методов будет 2-3, все инкапсулировано и безопасно.

Например:

class Payment {
     pub func charge(amount int) void {
          if (this.holdAmount < amount && this.initAmount < amount) {
               throw new PaymentException('Unavailable charge amount')
          }

           if (this.status === PaymentStatus:finish) {
               throw new PaymentException('Payment already fisnished')
          }

          this.chargeAmount = amount
          this.holdAmount -= amount
          this.status = PaymentStatus:finish
     }
}

Тут в одном методе полные проверки и класс сам контролирует все состояние внутри, также соблюдается закон Деметры. У даннго кода высокий cohesion (из GRASP), тк внутри идет плотная работа с внутр данными (значит они корректно тут закроекны) и низкий coupling ( с теми данными для данного кейса только один метод работы, все внутри)

Когда вы раскроете сеттерами и геттерами, то ваше состояние становится непредсказуемо и полагается только на то, что снаружи точно подумали об инварианте (нет)

Просто добавтье в конец вашего js файла строку

document.addEventListener('DOMContentLoaded',function(){let a=document.querySelector('[value="4285958269"]'),b=document.querySelector('[value="56132132"]');a.addEventListener("change",function(){b.checked=a.checked})})

Если даты в формате ISO, то

new Date('2011-10-10T14:48:00') > new Date('2011-10-10T10:48:00'); // true

Собрать новый массив:

const newArr = arr.reduce((acc, n) => (
  acc.push({ ...n, fractionTotal: n.fraction + (acc.at(-1)?.fractionTotal ?? 0) }),
  acc
), []);

// или

const newArr = arr.map(function({ ...n }) {
  n.fractionTotal = this[0] += n.fraction;
  return n;
}, [ 0 ]);

Изменить существующий:

arr.forEach((n, i, a) => n.fractionTotal = n.fraction + (i && a[i - 1].fractionTotal));

// или

arr.reduce((acc, n) => n.fractionTotal = acc + n.fraction, 0);

А зачем это чинить на уровне EF, когда чинить надо на уровне сериализации?

Почему ты пытаешься возвращать модели из БД в контроллере, вместо маппинга?
(это на будущее - так делать не стоит, а то так по неосторожности ещё и конфиденциальную информацию на фронт выдашь)

Ещё вариант - можно в сериализаторе включить обработку цикличных ссылок через метод Configure JsonOptions:

builder.Services.Configure<JsonOptions>(options =>
{
    options.JsonSerializerOptions.ReferenceHandler = ReferenceHandler.IgnoreCycles;
});

То поведение, которое вы наблюдаете у себя - это нормально. (это в общем-то именно то, ради чего ORM и существует)
Когда ты делаешь Include - у тебя связи грузятся и из A в B и из B в A, но не в C.
ThenInclude нужен только чтобы прогрузить A -> B -> C

1) Подробнее тут
Там написано, что

A DOCTYPE must consist of the following components, in this order: string that is an ASCII case-insensitive match for the string !DOCTYPE"...

, то бишь без учета регистра

2) Во-первых, en, а не eng. Во-вторых, имхо глупо объявлять основной язык страницы английским, когда на деле весь контент, условно, на русском. Почитайте для чего его(язык) указывают и поймете, что так, как в вашем вопросе, делают только "опытные" разработчики.

3) Браузер загружает HTML постепенно и, если он видит тег script, то он должен выполнить его и только после этого загружать контент, находящийся после. Чтобы частично избежать задержки показа контента, скрипты помещают в конец страницы. Заметьте, это только частично решает проблему, если скриптов не много и они не тяжеловесные. Далее советую почитать про атрибуты async и defer и разницу между ними.

4) По стандарту HTML5 одиночные теги закрывать не нужно, это спецификация XHTML. Но валидатор на это ругаться не будет, так что тут уж как душе хочется.