Василий Банников

Если апи этого не предоставляет - никак.

Да и в том то и прикол языковой в том, что как раз классифицировать архисложно.
"Какой бы фильм посмотреть" - не относится к медикам.
"Какой фильм посмотреть медикам" - относится в какой то степени, но не факт что будет спрашивать медик.

Как вы считаете, что мне лучше делать в этой ситуации?

1. Перестать верить в деда мороза и розовых единорогов.
2. Работать дальше.
3. Учиться, учиться и еще раз учиться.

так занесите в сервис
мало ли, коротнет что то - тогда апгрейд будет веселый

Это не самый "нежный" разъём. Я бы отключил. В том числе чтобы избежать таких случайностей, как болтик упал в неудачное место на плату и устроил коротыш. Ну и за компоненты спокойнее будет.

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

Суть хакатона.
Берем 100 команд.
Говорим им, работать над идеей в области такой-то.
Воруем идею.
Начинаем реализовывать с участниками понравившейся идеи.
Потихоньку выкидываем всех, кто эту идею придумал, реализуем нормальной профессиональной командой.

может есть какие-то утилиты

Конечно есть :)

Kaspersky Antivirus
Dr.Web
Malwarebytes (я предпочитаю вот этот)

или практика по данному вопросу

И практика есть - и ею поделится любой ИБ-шник :)

Не пихать в комп подобранные на улице флэшки
Не ставить кряки, хаки, пуки "от Васяна" - это уже давно не безопасно
Не открывать ссылки в почте. Вообще никакие (нубу и чайнику лучше перестраховаться)
Не ходить по подозрительным сайтам без блокировки скриптов и резалки рекламы
Не отключать UAC! Лишний "глупый" запрос может вовремя остановить!

Словом примерно то же самое, чего придерживаемся в личной жизни :)

Если было бы больше контекста, то можно было бы что-то увереннее советовать. По этому куску кода можно дать только такие комментарии (считая что Get* методы и итераторы не имеют сайд эффектов):

var someItems = _someService.GetList();
foreach (var item in someItems) // item внутри не используется, можно убрать этот foreach
{
    var additionalItems = _additionItemsSerivce.GetList();
    foreach (var additionalItem in additionalItems)
    {
        var properties = additionalItem.Properties;
        foreach (var property in properties)
        {
            property.First = true;
            property.First = true; // зачем делать одно и тоже два раза?
            _additionItemsSerivce.UpdateProperies(additionalItem); // property не используется, значит можно вынести за этот foreach
        }
    }
}

Если по этим комментариям убрать лишнее, получится что-то такое:

var additionalItems = _additionItemsSerivce.GetList();
foreach (var additionalItem in additionalItems)
{
    var properties = additionalItem.Properties;
    foreach (var property in properties)
        property.First = true;
    
    _additionItemsSerivce.UpdateProperies(additionalItem);
}

Так же странно что все проперти у вас получают флаг First, возможно вместо foreach по properties стоит получить только первый элемент и ему установить First = true.

Надо посмотреть в суть вопроса. Откуда вообще он идет. Очень часто программисты оптимизируют не то и не там. Иногда они оптимизируют "от нечего" делать. Или от предубеждений что каждый цикл надо оптимизировать.

Что по поводу этого куска кода думает бизнес? Его это беспокоит? Действительно ли этот кусов влияет на какую-то внешнюю оценку. Может он работает в составе джоба и занимает 1% времени?

Откуда вообще возникает list? Если из базы данных - то возникает вопрос. Можно ли сделать UPDATE прямо в базе данных без пере-сохранения в объекты.

Если надо только в объектах и если накладные расходы идут на объекты - то можно попробовать развернуть объекты на 90 градусов и сделать из них массивы примитивов. По ним поиск пойдет быстрее. Но такой подход
специфичен для bigdata, где есть WORM (Write Once Read Many). И нужно еще доказать что разворачивание объектов даст в итоге полезный эффект ведь накладные на сам процесс разворачивания никто не отменял.

Lan - «тип» подключения(локальная сеть)
Патч корд - провод.

В случае с названием провода - это олно и тоже

Ты должен спрашивать какие алгоритмы игровой графики бывают. Это важное. А константа - это просто реализация.

Почитай Генри Уоррена - Алгоритмические трюки для программистов. Там есть всякое. Деление через умножение на магию. Умножение через сдвиги. Дискретные логарифмы и корни и прочее.

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

Разумеется, свойства необходимы, если мы планируем использовать паттерн Наблюдатель(Observer), который в C# реализуется через интерфейсы INotifyPropertyChanged и INotifyPropertyChanging. Если вкратце - если мы хотим, чтобы другие объекты могли подписаться на наш объект, и получать уведомления об изменении его состояния. Тут всё понятно - сеттер свойства будет эти уведомления рассылать.

Также свойства могут выручить, если мы потом захотим изменить способ хранения данных, но не захотим изменять "внешний вид" (интерфейс) объекта. Тогда в геттер свойства можно будет поместить код, который пересчитает "внутреннее" представление свойства во "внешнее".

В случае примитивных data transfer objects, как User в твоём примере, я не вижу особенного смысла в использовании свойств ради свойств. Я бы даже сделал его struct, а не class, но это уже пусть спецы по C# меня поправят.

Вообще, любую рекомендацию по проектированию нужно рассматривать не как заповедь, а как некий размен (trade-off): мы выигрываем в X, но проигрываем в Y (зачастую Y = сложность кода). И, соответственно, смотреть, что для тебя важнее.