Тогда if-else достаточно. Тем более, что проверяется булева переменная, у которой всего два варианта может быть.

Я ещё функцию в несколько строк заменил на однострочную

было

bool result = true;

if ((myObject != null) && myObject.BooleanProperty)

{

result = false;

}

return result;

стало

!myObject?.BooleanProperty ?? true;

Или можно было так, без оператора ?? (подошло бы даже для самых ранних версий фреймворка - с использованием оператора ? :)

myObject != null ? !myObject.BooleanProperty : true;

Но тут можно объяснить, что код писали во времена дотнета 2.0, потом проапгрейдили кое-как до 4.х, но сам код не трогали.

Причём мой вариант хоть и короткий, но типа более запутанным выглядит. На самом деле и начальный вариант тоже запутанный. Если так охота явно раскрывать все ветвления, то в условиях if не должно быть сложных конструкций - должно проверяться ровно одно условие, а все остальные - уходить на другие (вложенные) проверки.

Если бы даже я писал первый вариант - и то сделал бы проще, типа такого

if ((myObject != null) && myObject.BooleanProperty)

{

return false;

}

else return true;

Но опять же, писали либо гении, либо какие-то замороченные паТТерналисты. Или просто чел фигачил первый попавшийся вариант из головы. Говнокода в этом проекте много - каждая небольшая бизнес-логика расписана на сотни строк - поэтому фигачить надо было в темпе. Сейчас переписываем и буквально выкидываем код тысячами строк - столько там пипец лишнего понаписано. Челы там для самых первых версий ASP.NET (без MVC ещё) написали свой набор веб-контролов, привязки им там придумали, свою ORM, подходящую для нескольких БД, но кривую, косую и очень ограниченную, работающую хитровыепанным способом, заточенную на САМУЮ ПЕРВУЮ версию Hibernate (т.е. своя ORM над кривой первой версией чужой ORM). Маршаллинг-куяршаллинг, динамическое удалённое (на сервере) создание типов (не просто объектов, а типов) по XML-описаниям на клиенте. Формат описаний и прочее - самописное. Т.к. изначальный фреймворк (ASP.NET) - stateless, то внедрена самописная statefull-обёртка для сохранения состояний. Всё крутится типа на сервере приложений, где вращаются созданные бизнес-объекты, а клиентам передаются их "слепки". Что-то типа современных сетевых игр, где игровая ситуация полностью моделируется на сервере и потом клиентам передаётся ограниченный набор данных для отрисовки изображения. Всё это овно тупо не заводится на современном фреймворке, а надо переписать не на дотнет фреймворк, а на новый "просто дотнет", из которого выкинули кучу старых библиотек, и теперь старый код надо либо полностью переписать, либо отказаться от него. Вот от напичканного самописными костылями и чрезмерными усложнениями сервера приложений отказались.

И зачем-то в этом проекте логируется практически каждая более-менее значительная операция. Типа запросил объект из БД - залогировал, что запрошен такой-то айди и кучка дополнительных данных. Ошибка при запросе? - Залогировал. Успешный запрос? - Залогировал. Короче, юзер кнопку нажал - в логи штук 10 строк ушло. А юзер жмёт эти кнопки по 20 раз в минуту. Т.е. в минуту с одного юзера килбайты логов. Это если ошибок нет. Если есть - в разы больше. И таких юзеров на предприятии - сотни и тысячи. Представьте, сколько нужно хранить логов за годы работы такой системы? Жётские диски, наверное, грузовиками завозят.