сорри, в синтаксисе delphi не силен, но, может быть, что-то в таком стиле:

2 логических переменных образуют 4 состояния, закодированные в виде 0,1,2,3,

edtObject.VisibleedtSubject.VisibleInteger(edtObject.Visible)Integer(edtSubject.Visible)(Integer(edtObject.Visible) + 2*Integer(edtSubject.Visible)) FalseFalse000TrueFalse101FalseTrue012TrueTrue113
Это наглядно, и понимать здесь особо нечего.
Простое принятие решения на основе значения выражения.

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

да, себя-то вы и не читаете...

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

кстати, в этих терминах, по вероятности, прототип кода (с вероятным будущим делением) выглядит как-то так:



совершенно очевидно, что это безусловно наказуемый подход за недостаточностью ифов.

В триаде "пользователь"-"компьютер"-"другой программист" я - другой программист.
Для меня именно эта форма минимизирует шанс при первом чтении неверной интерпретации кода в целом или пропуска важной детали.

Само выражение вычисляющее вариант - случайно, а форма дает возможность однозначно связать в единое целое происходящее дальше с происходящим ранее.
Для меня это вопрос о потере времени на понимание, вероятности пропуска деталей, приводящих к ошибке в модификации существующего кода.
Сколько раз надо пройти по исходному коду глазом сверху вниз и наоборот, просто для того, чтобы сформулировать правдоподобную
гипотезу о смысле происходящего, и сколько раз в варианте с вычислимым case statement (для меня ответ очевиден).
И сколько еще раз к этому надо добавить, чтобы убедить себя в том, что ты не ошибся точности интерпретации и не упустил детали...

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

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

Конечно, я исхожу из того, что "программирую, как все", и то, что удобно для меня, автоматически удобно и для всех других программистов .
Поскольку суждение субъективное, оно имеет право произвольным образом не совпадать с чьим-то другим субъективным мнением.

Вовсе нет. Именно комбинация в битовый вектор здесь почти случайность, выбранная только для немедленной совместимости с
предыдущей версией кода без внесения в него дополнительных предположений об устройстве интерфейса или внесения изменений в
иные части программы.


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

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

Главное , что сделал DHDD - разделил их на независимые фрагменты, годные к немедленному превращению в цепочку параметризованных функций.

Смысл предложенного мной улучшайзинга для фрагмента выбора опорного контрола состоит в переходе на шаге выбора
отображенного контрола от прямого опроса свойств объектов формы для выявления текущего состояния к работе с явно
задекларированным абстрактным состоянием компонента. И прямая битовая комбинация, образованная в моем посте лишь шаг, позволяющий привести конкретный фрагмент кода к виду, лучше соответствующему этой идее без внесения немедленных глобальных изменений в проект. Это часть возможной постепенной миграций от замусоривания кода прямыми опросами свойств контролов к работе с абстрактными состояниями абстрактных автоматов.
Утилитарный код при этом, со временем, целиком избавляется вообще от каких-либо ифов и делает свою простую или циклическую работу.



Вот именно - природа задачи .
И тот, кто формирует список таких котролов, чтобы потом натравить на него простой цикл выравнивания (не содержащий ифов),
вполне может ориентироваться прямо на текущий код состояния автомата визуального состояния.
Форма case statement отлично обслужит и эту потребность.

И дело не в том, что case "вообще лучше", чем if, а, имхо, в том, что case отшелушивает конкретику мозговыносящих комбинаций конкретной версии визуального интерфейса, оставляя при этом возможность дальнейшего абстрагирования и замены себя впоследствии на "более подходящий объект"