Тернарные операторы в 1С #806366

Уважаемые коллеги! Есть ли у вас какие-то правила (для себя) по использованию тернарных операторов определенного уровня вложенности? (например, не использовать тернарный оператор внутри тернарного оператора). И вообще, используете ли вы его? Наткнулся на следующее Г, поэтому и возник вопрос:

это Г только если это не твое Г )

Использую не больше 1 вложенного. Пример из вполне читабельный.

Использую. Регулярно. В т.ч. вложенные. Как правило при формировании какой-либо строки (например, текста запроса). Но бывает и подобное , если есть чёткое булево условия как в , то почему бы и нет?

+1

А если переписать вот так:            );

Он читабельный, т.к. на мисте шрифт мельче, чем в конфигураторе (скажем, EDT-style) В конфигураторе это 176 символов, не помещается в экран

+ хотя формирование даты просится отрефакториться в функцию

лучше так

я и отрефакторил в функцию. Еще заменил "?" на "Если", а то не очень удобно смотреть, хоть и в одну строчку

Не лучше. Три присваивания вместо одного - потенциальный источник проблем.

нормально читается так: При рефакторинге имеет смысл переделывать на Если ... КонецЕсли;

Я бы всё это вынес в функцию.

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

ну и можно еще так Если не Шапка.ЭтоУвольнение Тогда

Не использую дичь вида ?

Я бы сделал так: то есть добавил бы это: ПериодРегистрации = Шапка.ПериодРегистрации;

Использую, причем но не более 3-4 вложенных. Далее просто становиться не читабельно.

за такой перенос запятой 1С смело разворачивает конфу на исправление

ты про запятую в начале в функции Дата? это мне тоже не нравится

? использую, но без вложений

15                 ),

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

1С может ходить нахер. Или пусть опубликуют codestyle. В таком стиле ты никогда не пропустишь и не забудешь запятую.

+1

Это хорошо, когда платят за количество строк кода. Как по мне, так чем более кратко, тем лучше. После Perl, наверное )))

в именно про запятые ничего нету

А почему 1С решила извратить этот классческий оператор?

В нашем деле, главное - читаемость кода. Вложенные "?" читаемость портят.

Взяли за основу С Вот так красивее:

А разве не так:

1С вообще сделали этот как-бы , каковой он не является. Зато в 7.7 с его помощью делалась "ленивая" проверка условий.

Использую без вложенных. Пример вполне читабелен, но от вложенного ? я бы все равно избавился.

Да тоже, когда язык проектировали, забыли как пишется.

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

хотя для ? они все аргументы не вычисляют

сложные условия обычно объединяют(речь не про 1с) в переменную. Фиксин по моему даже писал где-то об этом

Синтаксическая глюкоза от 1С (:

что в ? что в ЕСЛИ - проверка ленивая

в 7.7 нет

Тогда уж голосовалку. Код в очень даже норм.

да

правило простое - тернарные операторы должны быть простыми и укладываться в голове с одного прочтения. Если приходится читать по частям, то надо рефакторить. Код в топике - УГ, фу так делать

Да вроде норм. С одного раза все понятно

вот как надо

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

поэтому самый наиприемлемый варинат

и зачастую, когда в запросе наворотишь условий со всякими И / ИЛИ, да ещещ перевложенными в скобочках, чтоб понимать суть условия приходится  делать отступы и потом НЕ ПОЛЬЗОВАТЬСЯ конструктором, чтобы потом вся "логическая"не слетела нах, после его "стандартизации"

* "логическая Красота"

А вот если в запросе наворотишь вот это всё, то это 100% рефакторить надо.

Для себя решил так: вложенные конструкции в "?" не использовать.

Только если под настроение для прикола могу навернуть:-) А вообще стараюсь если есть вложенность, то использовать Если...Тогда. Потому что потом сам материшься спустя какое то время разгадывая  этот ребус:-)

А вот если бы в SQL писали бы не select case     when x>1000 then y1000     when x>100  then y100     when x>10   then y10     else             y0 end as Y а вот так (а ля Си-лайк): select Y = x>1000    ? y1000    :     x>100    ? y100    :     x>10    ? y10    :                   y0

select case в запросах 1с прекрасно реализован