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

тот же тернарник, с меньшим количеством состояний, может с точностью повторять проблемы которые ты описал

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

вот только его смысл не создание сайд эффекта, а возвращение значения

и да. и нет. чем меньше кода в операторах тернарника – тем сложней его сломать. Сегодня у тебя там простой возврат значения из массива с учетом математики получения индекса. а позже формула усложнилась и последующая поддержка этого “чуда” может грозить проблемами в стабильности.

не забывай про такой чудный сайдэффект разработки, что спустя время ты же сам будешь материть того кто “это” написал, а потом драть волосы со стыда когда заглянешь в аннотации)

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

пф…. регулярно.  нет предела совершенству

на то и существует рефакторинг и tdd

а еще есть менее просвещенные коллеги, которые могут случайно сломать что-то что выгяледело как “ой да ладно это ж просто”

уф… ну прям за уши притягиваешь. с такой логикой ни одного джуна не стоит и на километр подпускать к коду написному в соответствии с solid, ооп и хоть как то использующим паттерны проектирования

нет

чем проще для восприятия человеком код – тем проще его поддерживать в дальнейшем. Тем легче будет этот код покрывать тестами и следить за состояниями и тп. Да будет небольшой оверхед при работе этого кода. Но с учетом того что у нас сейчас в карманах мощности железа больше чем (к примеру) у меня на столе в ноуте – это не большая цена за возможные проблемы в затягивании релиза из-за новых багов от новых фич.

Возвращаясь к тому тернарнику:
- раскидав его на 3 метода – ты можешь покрыть их тестами и  быть в будущем уверенным в стабильности каждого из методов. В варианте которы был предложен - это одна конструкция которая имеет больше вариантов сломаться. Но! Эта конструкция, которую предлагали в чате, вообще не предполагает тестов. Потому что оно инлайново присваивается в константу/переменную. То есть конечный код уже разбух настолько что количество состояний для ошибки становится, условно, запредельным.

и возвращаясь к ФПшникам – там вроде чем меньше функция тем больший дзен получается

я согласен, о том и говорю, что вопрос со сложностью восприятия тернарников лежит не в плоскости самой конструкции, а в плостоксти декомпозиции кода, композиции функций. наговнякать можно и в hello world приложении. при этом мы сейчас обсуждаем 2 разные конструкции - императивный if который сделан для создания сайд эффекта и тернарное выражение которое предназначено для возврата значения и не более

плюс минус. там больше о том что сделать, а не о том как это сделать

для меня этот код лучше чем его изначальная форма

речь о вот этом виде https://t.me/frontcoder/119836

оке) забери из функций возвращающих значение возможность делать доп вычисления или обращаться к полям о которых они не знаю и утебя получится пайплайн
лист -> получить список элементов по определенному алгоритму -> модифицировать список (изъять из него значение) -> проссумировать значения любого списка

а что делать если обе формы нравятся? :)