я чот не пойму, а что в этом варианте не по фен-шую?

Очень даже много

1. Проверяется всего лишь одно поле, жирно слишком будет, по свитчу на каждое поле.

2. Если Age будет нуллабле и мне нужно будет отличать варианты или объект null или возраст null (не указан), то приплыли.

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

Если вопрос про красивости, то такой код на код-ревью я бы не принял. Во-первых затраты на его понимание превышают пределы чтения тривиальной проверки на null и тернарного оператора ?:. Во-вторых, а соответствует ли он Kodierrichtlinien? В третих, такая нотация предполагает знание Linq в контексте SQL, что является избыточным для тривиального куска кода общего назначения. Короче, привнесена специфика туда, где она даром не нужна; не будет сходу всем понятна и на нее нужно тратить время. Но это ИМХО конечно же.

это я твой код чуть переделал, остался только один дискард. Комар AlexNek носа не подточит

Теперь ещё мой вариант с кортежами переделайте, чтобы тоже не подточил.

решение чего?

-------

Проблемы двух и более срабатывающих кэйсов в одном свитче.

А решение - последовательное вычисление каждого условия... и - да - результат начинает зависеть от положения селектора, но прикладники сказали что им пофиг...

Если у вас срабатывают более одного кейса, значит у вас должно быть больше кейсов - где-то вы не поделили один кейс на несколько. А я предложил то же решение, что и у вас, но вместо последовательного перечисления одного кейса за раз, а проверяю кейсы попарно, потройно и т.д. за счёт ключевого слова when. Это позволяет объединить проверки в группы по их логике. Плюс кортежи - ещё удобнее.

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

Во-первых затраты на его понимание превышают пределы чтения тривиальной проверки на null и тернарного оператора ?:.

Проверка на налл и этот ваш оператор могут максимум 4 кейса проверить. Кроме того, в вашем случае вы смешиваете разные операторы - сначала if-else (на налл), затем ?:. У меня всё проверено единообразно в 3-5 строчек, а не на треть экрана расписано. По сути у меня понятная и удобная таблица истинности, а не кучка разномастных операторов.

Во-вторых, а соответствует ли он Kodierrichtlinien?

Смотря какие linien. Но странно, если они будут запрещать использовать свичи и вообще всё новое из новых версий Дотнета, хотя проект именно на этих версиях написан. Зачем на новые версии переходить тогда? Последняя Виндовс поддерживает в том числе и старые версии Дотнета - старпёрь, не хочу.

В третих, такая нотация предполагает знание Linq в контексте SQL, что является избыточным для тривиального куска кода общего назначения. Короче, привнесена специфика туда, где она даром не нужна; не будет сходу всем понятна и на нее нужно тратить время. Но это ИМХО конечно же.

Линка там нет. А кто не знает язык - его проблемы. Может, мне на второй версии Дотнета писать, а то кто-то в 20-летней давности застрял? Объективно, у меня нет никаких ребусов, над которыми надо было бы ломать голову, а кортежи и свичи - это уже считайте азы.

Насчёт сходу всем понятна - те, кто изучают язык с последних версий, могут как раз не понять портянку if-else вместо удобной таблицы истинности, записанной свичом, постоянные проверки на налл через те же if-else вместо null propagation. Вобщем, всё относительно. Но идти на поводу у старпёров, которые дальше второй-третьей версии Дотнета и языка не ушли, нет смысла. Особенно, когда сам проект на одной из последних версий.

"Красивости" это только звучит "даром не нужно". Но если это позволяет записать код в 3 раза короче, умещая на один экран, то это делает его зачастую и понятнее, т.к. не надо скроллить туда-сюда, теряя контекст.

По сути у меня понятная и удобная таблица истинности

Есть такое предположение, что она будет понятна и удобна исключительно автору

Мы вам перезвоним...

Ну я же упомянул ИМХО, не злитесь. Когда-то Страуструп сказал, что мы не может ориентироваться на невежество читателя в написании кода (что-то в этом духе), но к сожалению эти времена прошли. Сейчас времена аджайла, среднестатистического разработчика, спринты, тайм ту маркет и вообще приближение индустрии 4.0. Гении не нужны - "Не дядя Вова, скрипач не нужен"

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

Свитч выражения введены в 8 версии Сишарпа в 2019 году, с первой версии Дотнет Коре. Зачем нам переходить на Коре, если мы сидим на скажем третьей версии (2006 год)?

Видел команды, которые пишут на WPF как на формах - не используя привязки, шаблоны, стили, словари ресурсов, команды - вобщем, ничего из MVVM. Просто фигачат в code-behind, вместо стилей повторяют все настройки представления для каждого элемента копипастингом, если они одинаковые. Крутые сеньёры, уже много лет поддерживающие крупный проект для крупных фирм. Походу, они и разметку не использовали, а лишь визуальный редактор форм - что генерилось в разметке, их не интересовало. Непонятно, зачем им нужен был WPF. И вот такие чудаки обкладываются всякими linien - сами нормально не пишут, и другим не дают.

Зачем нам переходить на Коре, если мы сидим на скажем третьей версии (2006 год)?

Кстати да, а зачем переходить? Какие-то есть обоснования к переходу? Мы закроем какие-то бизнес-кейсы? Или давайте просто потратим деньги?

Видел команды, которые пишут на WPF как на формах - не используя привязки, шаблоны, стили, словари ресурсов, команды - вобщем, ничего из MVVM

Легаси код. Интересный вопрос: нужен ли редизайн или мы остаемся консистентными? Как сами думаете?

сами нормально не пишут, и другим не дают

Вот жеж ... нехорошие люди. Как жить-то? Нужен манифест джунов, ибо им там не здесь, не посрамим и т.п. Вам самому не смешно?

Есть такое предположение, что она будет понятна и удобна исключительно автору

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

Проверяется всего лишь одно поле, жирно слишком будет, по свитчу на каждое поле.

вообще пофиг. Если решение занимает вместо 15 строк всего 5, то я за

Если Age будет нуллабле и мне нужно будет отличать варианты или объект null или возраст null (не указан), то приплыли.

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

Происходит инверсия понятий - дискард вешается на "нормальный" вариант.

в какой-то библии написано, что дискард обязательно должен обрабатывать нештатные ситуации? Рассматривай его как обычный else, не забивай себе голову.

Зачем нам переходить на Коре, если мы сидим на скажем третьей версии (2006 год)?

Кстати да, а зачем переходить? Какие-то есть обоснования к переходу? Мы закроем какие-то бизнес-кейсы? Или давайте просто потратим деньги?

Если долго не переходить, то потом можно закрыть не бизнес кейсы, а бизнес вообще.

У нас тоже лет 15-20 не переходили, а потом МС поддержку IE зарубила, и пришлось всё приложение переписывать. Ну зато копеечки по постепенному и планомерному переходу экономили. А сейчас - срочно нужно вбухать много денег и в темпе вальса свинга переписать почти всё, а что не переписать - то есть застарелое самописное дерьмо, хреново косящее под Entity Framework. Т.е. это тоже надо переписать, а точнее безопасно удалить и заменить на EF.

нужен ли редизайн или мы остаемся консистентными?

бронзовыми

2. Если Age будет нуллабле и мне нужно будет отличать варианты или объект null или возраст null (не указан), то приплыли.

Ничё не понял. Напишите пример. Если у вас есть пачка if-else или что подобное, то любая такая древовидная структура трансформируется в пачку кейсов свича (и обратно). Только не увлекайтесь этими развесистыми деревьями - когда у вас эта хрень начнёт уезжать за экран, вам предъявят, и вы сами захотите изменить со свичём.

дискард обязательно должен обрабатывать нештатные ситуации? Рассматривай его как обычный else

Любой else (т.е. дискард, дефолт и прочее "всё, что не предыдущее") может быть дальше расширен сколько угодно, если поступят такие требования. У Алекснека же требования всё возрастают - наллы во все поля повводил?

вообще пофиг. Если решение занимает вместо 15 строк всего 5, то я за

Не согласен. Не в общем случае. Есть разные строчки. Посмотри на пёрл. Вот где разгул для сокращателей. Только месяц спустя сам автор не мог объяснить что же он своим !__$@x.{__?$%x} хотел сказать. Зато одно строчка вместо 3.

5 if-else заменить на switch? Отлично. Но если мне для этого придётся писать brainfuck-подобный код, то лучше остаться с ифами.

потом мы удивляемся, почему в Германии не создаются никакие продуктов мирового масштаба.

Точно, вы открыли мне глаза, теперь я знаю отчего в Германии не очень высокая рождаемость.

Недостаток женщин с пирсингом - это же так круто и бабанькам с закостенелым мозгом это не нужно.

Рассматривай его как обычный else, не забивай себе голову.

дело то не в этом.

Во первых, switch expression лучше сравнивать с switch statement. И как часто, в части "по умолчанию", используется "это нормально".

Во вторых, условие - "всё что не проверено это хорошо" часто не очень хороший выбор. Ну вот, что будет если возраст будет отрицательным и мы это не проверили?