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

.

Пришлось построить в уме логическую конструкцию и упросить ее. Секунд 10 за это время, наверное, прошло.

Это же простейшие условия...

Из чего возник такой вопрос?

Бывает ещё понятней?!

(0) В каком контексте вопрос?
Если речь про алгебру логики, то тут элементарно по определению конъюнкции и дизъюнкции.
Если речь про программирование, то надо уточнять, про какой ЯП идет речь.

(0) Элементарно.

(6) Речь в первую очередь про встроенный язык 1С. Интересно, в каких других языках будет непонятно?

это из математической логики

не (А или Б) = не А и не Б
не (А и Б) = не А или не Б

(4) Вопрос возник из-за замечаний к моей методике оформления сложных логических выражений http://catalog.mista.ru/public/152801/ . По мнению некоторых коллег она затрудняет восприятие/понимание/чтение именно за счет этих фрагментов. Поэтому я решил узнать, какой процент программистов будет испытывать сложности с чтением таких выражений.

если помнишь логику - то понятно. если не помнишь - то в ступоре.

(0) несколько лет назад перестал нормально их понимать, наверное старею

раньше на лету как-то схватывал

(8) Если про 1С, то надо уточнять 7.7 или 8.х, поскольку в них поразному реализовано раскрытие логических условий.

Всё понятно, но я сам предпочитаю оформлять вот так:

Если (
    Условие1 Или
    Условие2 Или
    Условие 3
)
Тогда

КонецЕсли;

(10) мне кажется что нормально у тебя с записью

(10) Выражение понятно вполне, но с мнением некоторых коллег я полностью согласен - это не упрощение, это ненужное усложнение.

видимо автор хочет применить функциональный язык в 1с :)


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

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

(14) мне кажется что красивее будет так:
Если ( Условие1
   Или Условие2
   Или Условие3 )
Тогда

КонецЕсли;

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

(17) Можешь пояснить, почему будет "не читаемо"?

(16)
Про "ненужное" очевидно спорное утверждение, т.к. в статье приведены довольно четкие плюсы.
Про "усложнение" непонятно в свете "1. Сразу понятно". Поясни, почему это усложнение, если любой такой фрагмент сразу понятен (не замедляет чтение)?

(20) классическим восприятием булевых условий является прочтение с лева на права без выделения блоков с более высоким приоритетом выполнения.

Именно по этому все сложные конструкции принято запихивать в начало условия, а у тебя все наоборото, сначало простое условие - потом сложное

(22) + немного добавлю

человек одновременно может воспринимать от 8 до 12 объектов, и примерно 2 секунды для него это "сейчас".

если человек тратит на прочтение выражения более 2х сек или в нем более 12 элементов - это уже тяжело для восприятия...

Ну а по сколько ты добавляешь операторы "якоря" (истина, ложь), то выражение перестает восприниматься целым и дробится ели оно чуть длиннее чем 2 сек или 12 объектов...

зы
ничего личного, это психология

(10) Лучше так не делать. Усложняет читабельность кода.

(24) Наибольшую ценность имеют аргументированные точки зрения.  Факт того, что имеет место некоторое усложнение выражения относительно его самого простого вида, я не подвергал и не подвергаю сомнению. Я хочу собрать статистику по величие этого усложнения. Для меня лично это усложнение меркнет на фоне преимуществ, которые дает такая форма для СЛОЖНЫХ логических выражений. Однако я не сразу это понял и потребовалось время чтобы привыкнуть, как и большинству из тех, кто стал применять ее. Поэтому если не сложно, опиши хотя бы в двух словах, в чем  ты видишь усложнение читабельности. Но прежде всего ответь на опрос =)

(23) "выражение перестает восприниматься целым" эту мысль пока не удалось понять. Ты читал статью и конкретно прием аналогии с отбором компоновки?

(10)Не все прогеры умеют абстрактно мыслить.
Трудностей можно избежать если переменные будут понятно называться.

(26) смотри (27)

(22) Думаю эти измышления еще менее близки и не менее споры для большинства чем моя методика =)

(27) Твою мысль также не понял.

(30)Чего не понятного?

(31) Напиши более развернуто. Возможно тогда мне удастся понять, к чему ты это написал.

(25) Как упрощаются - понятно. Я пока не понимаю необходимость в этом. Не нравятся скобки - избавляйся от скобок.

Читай комментарий Валерия К (klinval)  06.09.17 14:43 по ссылке.

(32) смотри (22), (23)

(33) Вижу, аргументировать утверждение "Усложняет читабельность кода" пока не очень вышло.

(34) Смотри (26)

(35) количество операторов увеличилось ???

(37) Да, бесспорно.

(38) выращение - одно и количество операторов выросло, значит В ОБЩЕМ случае это усложнение...

разумеется есть частные случаи где это не так :)

выращение = выражение

(39) Опять же бесспорно да. Так и я писал в (25), что с фактом усложнения я не спорю. Мне хочется понять насколько оно значимо и в чем конкретно каждый его видит. Судя по результатам опроса (0) оно незначительно.

Далее на (26) я так и не получил от тебя ответ. Это заставляет думать, что аналогия с отбором компоновки тебе не известна. На мой взгляд это самый эффективный прием не замечать привнесенное методикой усложнение и более того даже начать видеть упрощение. Упрощение восприятия здесь базируется на появлении простой визуальной структуры выражения, знакомой по дереву отбора компоновки.

Я тугодум)

(35) Выражения "Ложь Или" и "Истина и" бьют по мозгам. Вот объясни мне, зачем вводить дополнительную сущность?

Условие в виде:

(НомерИзменяемойКолонки = "4")
    Или (НомерИзменяемойКолонки = "5")
    Или (НомерИзменяемойКолонки = "7")
    Или ((НомерИзменяемойКолонки = "8")
        И (ГруппаРасчета = мИдГруппы7))

И понятно, и читаемо.

(43) В статье я перечисли все плюсы/преимущества. Но понимая, что большинству лень читать много скорее всего ненужного текста, я перечислю их тут
- повышает наглядность выражения после некоторого привыкания (аналогия с отбором компоновки)
- облегчает рефакторинг, т.к. позволяет четко видеть пути упрощения (устранения избыточности) выражения
- облегчает отладку, т.к. позволяет быстро комментировать(выключать)/раскомментировать(включать) фрагменты выражения
- позволяет дописывать комментарии к каждому узлу дерева
- сокращает левые отступы, вложенность условий, количество строк в коде по сравнению с некоторыми другими подходами

(44) ты не ответил на мой вопрос. Зачем нужны конструкции "ложь или" и "истина и"? И без них все эти плюсы работают. И добавляется еще один - не нужно привыкать к излишним сущностям.

(45) Конструкции нужны для придания первому условию в каждой группе того же начала (отступа и оператора), что и последнему.  И снова отсылаю к аналогии с отбором компоновки, которую все упорно игнорируют.
"И без них все эти плюсы работают"
Опровергаю
1. наглядность выражения, базирующаяся на аналогии с отбором компоновки исчезает
2. облегчение рефакторинга снижается опять же из-за снижения восприятия структуры выражения в целом.
3. облегчения отладки не будет, т.к. первое условие каждой группы нельзя будет быстро комментирорвать/раскомментировать без разбивки ее на 2 строки
4. комментарии к первому условию в каждой группе будет сложнее писать, т.к. будет непонятно, он относится в целом к группе или к первому условию группы

(10) Я так и делаю

(46) Все верно. А еще таким способом удобно составлять условия в текстовом виде, например для запросов. Размеры кода сокращаются, логичность повышается.
Если кому-то такая элементарная конструкция режет глаза, то что с ними будет если увидят сложное логическое выражение?

Тогда правильно писать
Если что-то
Тогда
   Блок операторов
Иначе
   Блокоператоров
КонецЕсли;

у меня по этим сокращениям ч0рный пояс

(46)
1 наглядности нет, оператор невозможно удержать в голове, ветвление тем более. То, что значение группы надо "вычислять", всё ломает и отвлекает от предыдущего кода и смысла вообще.
2 рефакторинг сложного Если не нужен, такой Если надо комментить целиком и рефакторить в ИначеЕсли
3 отладка на уровне изменения кода? это не труба, не нужно уже, 21 век
4 проще сделать проще, без нотации
1с не питон, то что кто то придумал отступы, не значит что отступам можно верить. То, что придумана нотация, веры тоже не добавляет. Код будет стоппером

Не понятно

все-же я не понимаю зачем это нужно

если условие не понятно - его надо вынести в отдельную функцию и не парить мозг людям....

вместо написания

Если Ложь
    Или НомерИзменяемойКолонки = "4"
    Или НомерИзменяемойКолонки = "5"
    Или НомерИзменяемойКолонки = "7"
    Или (Истина
        И НомерИзменяемойКолонки = "8"
        И ГруппаРасчета = мИдГруппы7)
Тогда



спокойно пишем

Если НужнаяКолонка("4","5","7","8") Тогда
.....
.....
.....


Функция НужнаяКолонка(п1,п2...)
Результат = Ложь;
Если НомерИзменяемойКолонки = "4"
    Или НомерИзменяемойКолонки = "5"
    Или НомерИзменяемойКолонки = "7"
    Или (Истина
        И НомерИзменяемойКолонки = "8"
        И ГруппаРасчета = мИдГруппы7)
Тогда Результат = Истина; КонецЕсли;

Возврат Результат;

КонецФункции

(54) Ну как же - комментировать блоки, наример, ну и построковый переход при отладке

(54) Все верно, только внутри функции нужно условие начать с:

Если Ложь
....

(56) да внутри  функции - вообще пофик читабельно или нет будет...

(54) + кстати этот прием имеет и огромные плюсы, иногда эту функцию можно вынести в модуль повторного использования, что может существенно повысить скорость выполнения кода

(54) Уводишь вопрос в другую плоскость. Мы рассматриваем запись сложного логического выражения независимо от его роли в вышестоящей конструкции. Это может быть Если...Тогда, присвоение, возврат и прочее.

(0 || A ) & (1 & B) = A & B

По результатам голосования пользователи миста разделились на три группы:

1. непонятные
2. очень честные
3. очень тупые

согласен с vde69, вопрос из разряда: как делать неправильно?
если условие сложное, его нужно переосмыслить, а не не придумывать уродливые конструкции, и интересоваться потом, какое из уродств, менее уродливо.

(62) Он просто не понял.
Если один раз это переосмыслишь, то второй раз будет уже легко читать такое выражение. Оно будет казаться привычным и родным, как своя рука.

(54) Пишется "всё же"

(59) "независимо от его роли в вышестоящей конструкции" когда приходится так делать это называется "городить костыли" "лепить ворэраунд", стиль костылей хороший, он всегда хороший, когда есть

(63) Красивая аналогия.

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

(66) не очень хорошая аналогия...


есть вендор - "1с"
вендор пишет в своем стиле и рекомендует именно этот стиль
некая группа пользователей (а мы именно пользователи) говорит - мы будем использовать нотации не рекомендованные вендором, мы считаем, что если другие пользователи воспримут наш подход - им будет лучше....

только вот вендор как писал в старой нотации так и будет продолжать. Кроме того принятее сабжа может привести к проблеммам с постановкой "1с-совместимо"

(68) Да ладно уж, что тут говорить про вендора, на всю жизнь запомнил рекомендации по оформлению кода и желательные требования к самому коду, когда 1С только выпускала восьмерку. Там были "пожелания" 1С, чтобы процедуры и функции не превышали по возможности 300-400 строчек, а потом поглядел запросы в той же зарплате на несколько тысяч строчек и вопрос о "рекомендациях" 1С отпал сам собой. 1С пишет не так как сама рекомендует, а так как могут ее разработчики...

(63) переосмысление условия делается не только для того, чтобы его было легко читать. Если уловие сложное, в нем собрано много проверяемых параметров, то есть высокая вероятность, что часть из них не стоило вычислять, или стоило их проверить раньше и вернуться из функции раньше.
Разбор сложных условий нередко заканчивается не просто их "перетусовкой" в поисках лексического изыска, но и влияет на сам аглоритм. Поэтому это не вопрос вкуса, а конкретное место, где стоит подумать над условием как таковым.

(70) В сложном условии небольшая добавка вообще как капля в море влияет на усложнение даже для того кто не привык. С другой стороны на упрощение она влияет больше. Так что лучше ставить чем не ставить.

(21)
Да все просто. Конструкция вида Логическая_константа и что-то там еще сразу наводит на мысль, что тут в условии что-то переписывали, отлаживали и вообще костыль. Больше времени тратится на то, чтобы убедиться, что это не так, а не на то, чтобы понять что сейчас делает выражение.
Естественно, если к такой нотации привыкнуть, тогда она будет читаться совсем легко.
А ненужным я называл этот прием, несмотря на перечисленные в статье плюсы, потому что это попытка починить то, что не ломалось. Типичный оверинжиниринг. Сложные логические выражения надо не записывать в какой-то изощренной форме, а просто избегать. Если возникает необходимость тулить условия с 4-5 переменными, то очевидно этот код хороший кандидат на рефакторинг.

(14) 1С рекомендует логические операторы писать в начале строк:

Если условие 1
    Или условие 2
    Или условие 3 Тогда

...

Пока получается соотношение тех, кто не испытывает сложностей при чтении, к тем, кто испытывает, составляет 12:5. Я ожидал около 5:1.

(68) (73) У вендора в этом вопросе проблема - явная обязанность писать Тогда в последней строке многострочного условия.
Эта обязанность напрочь убивает любую читабельность условий.

Здравый смысл и читабельность показывают, что:
* в однострочном Если писать Тогда надо в одной строке
* в многострочном Если писать Тогда надо в отдельной строке на том же уровне отступа, что и Если.

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

По 10 раз на дню пишем условные операторы.

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

Странно, но понятно

Сразу понятно, что толку от этого нет.

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

мусор какой-то

(81) Из твоего сообщения кажется, что ты пытаешься не ответить на опрос, а покритиковать мою статью. Я не против критики, но хотелось бы честных ответов по опросу.

(82) Почему тебе это кажется мусором? Видимо все таки понимаешь, как эти выражения упрощаются?

Сразу понятно. Наверное потому, что часто при отладке (особенно запросов в консоли) руки тянутся к "//" для временного отключения условий.
Ну и, соответственно, чтобы спокойно можно было комментить и первое условие тоже оно должно стать вторым :)
из

Когда //У1
Или У2

логично же сделать

Когда Ложь
//Или У1
Или У2

1) При всём уважении к автору, на мой взгляд опрос составлен не вполне корректно.
Ответы 2 и 3 выставляют отвечающего идиотом в большей или меньшей степени. Так что те кто потенциально могли бы выбрать эти пункты скорее всего пройдут мимо. Отсюда и высокий рейтинг первого варианта ответа.

2) Не могу сказать что мне СРАЗУ было понятно как упрощаются эти выражения. Конечно десять секунд не думал, может быть секунд пять. Нет, простейшие выражения булевой алгебры посчитались в голове почти мгновенно. Основная часть времени ушла на поиск того что здесь не так)) Сейчас конечно понятно сразу, особенно после прочтения статьи. Поэтому соглашусь с (78), тем кто часто такое использует будет понятно сразу, остальным не факт.

3) На мой взгляд наличие таких конструкций это bad design. Сам больше склоняюсь к варианту с переменными из комментариев к статье:

    Если Ложь
    Или НомерИзменяемойКолонки = "4"
    Или НомерИзменяемойКолонки = "5"
    Или НомерИзменяемойКолонки = "7"
    Или (Истина
        И НомерИзменяемойКолонки = "8"
        И ГруппаРасчета = мИдГруппы7)
    Тогда
        Расчет(ГруппаРасчета);
    КонецЕсли;


Заменить на

    
    ИзменилиРасчетнуюКолонку = (НомерИзменяемойКолонки = "4" Или НомерИзменяемойКолонки = "5" Или НомерИзменяемойКолонки = "7");
    
    ИзменилиКолонку8ИГруппаРасчетаВерная = (НомерИзменяемойКолонки = "8" И ГруппаРасчета = мИдГруппы7);
    
    НеобходимРасчет = ИзменилиРасчетнуюКолонку Или ИзменилиКолонку8ИГруппаРасчетаВерная;
    
    Если НеобходимРасчет Тогда
        Расчет(ГруппаРасчета);
    КонецЕсли;


Ещё позабавил комментарий про техподдержку)))


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

Поэтому исключительно для статистики ставлю

(75)Ты не тот срез аудитории взял. Тут,если ты поварился в 1С хотя бы несколько лет и не совсем гуманитарий, то само собой читать будешь сабж не задумываясь особо.
Если хочешь объективности- надо у студентов вузов спрашивать, без опыта работы

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

И то потому что не понял шо от меня требуется

(86)
"опрос составлен не вполне корректно"
Согласен, что варианты 2 и 3 могут быть обидными кому то и потому они могут просто воздержаться от ответа. Может быть у тебя есть идеи, как сформулировать так, чтобы было менее обидно (как сделать его "вполне корректно")? Если нет, то получается, что твоя критика не вполне корректна =)

(87) Как раз меня интересует больше всего категория программистов 1С.

(83) просто я пишу с оглядкой на отдел админов, которым потом мой код сопровождать :)
они точно не будут себе мозг полировать на таких выражениях, а скинут задачу на меня. оно мне надо? :)

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

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

вот это
Если Ложь
    Или НомерИзменяемойКолонки = "4"
    Или НомерИзменяемойКолонки = "5"
    Или НомерИзменяемойКолонки = "7"
    Или (Истина
        И НомерИзменяемойКолонки = "8"
        И ГруппаРасчета = мИдГруппы7)
Тогда


обычно пишу так
НаборКолонок = НовыйСоотвтетствие(4, 5, 7, 25,58,100500);//Сделан конструкттор
Если (НаборКолонок[НомерИзменяемойКолонки] <> Неопределено) и (НомерИзменяемойКолонки = "8" и ГруппаРасчета = мИдГруппы7) Тогда

(93), (94), (95) Снова прошу отвечать на опрос, а не на мою статью. Про статью я написал, как отправную точку возникновения опроса. В постановке вопроса (0) я же не прошу отвечать применительно к моей методике. Меня интересует время которое программисты 1С в среднем тратят на понимание таких фрагментов выражений.

Удобно для структурирования сложных условий, с количеством элементов более трех. Если до трех - проще без такого.

(95) Может массив вместо соответствия?

Идею вроде понял. Сам форматирую сложные выражения только переносами строк и отступами. Возможно, что не так часто приходится комментировать отдельные условия, поэтому задумываться над введением дополнительных "Ложь" и "Истина" не приходилось.

(98) с соответствием изящнее выходит, чем .Найти в массиве :)

(95), (100) Это частный случай.

А почему, собственно, такой вопрос у ТС?
Начинающий?

(102) Предыстория в (10)

понятно, сек 10 думал

А что тут непонятного?

1. Сразу понятно

Я дольше думал над вопросом: а над чем вообще тут думать)
Сам терпеть не могу такое. Идеально все приводить к "А и Б и...и N"

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

(105) слегка почитал комменты.
Согласен с теми, кто говорит про бредовость добавления Истина, Ложь в логические выражения.
В 1С можно писать по русски, поэтому надо правильно называть переменный и текст читается как просто предложение, понятное для восприятия....просто надо писать по-русски. А зачем скобки перед (А И Б) я так и не понял.

Думал минуты 2, искал в чем подвох.
Не нашел подвох.

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

(111) в (44) расписали плюсы. Вот примеры:
Если Ложь //Вот здесь можно указывать комментарий для всего блока
    //Или НомерИзменяемойКолонки = "4" - можно вот так комментировать даже первое условие при отладке, не дописывая для этого лишнего
    Или НомерИзменяемойКолонки = "5"
    Или НомерИзменяемойКолонки = "7"
    Или (Истина
        И НомерИзменяемойКолонки = "8"
        И ГруппаРасчета = мИдГруппы7)

В (99) я уже расписал, что крайне редко встречаюсь с необходимостью в этих плюсах, поэтому не использую такой подход.

(91) Я бы формулировал вопрос таким образом, чтобы понять, приемлемо ли вообще использование такой конструкции. Подозреваю что это и является конечной целью опроса)
Человек может понимать такое и сразу, но при этом каждый раз "плеваться". Кроме того сложности с пониманием могут быть связаны не с интерпретацией правил логики, а с поиском скрытого смысла в подобной конструкции.

(102) Спасибо, поржал)))

(112) Спасибо, пропустил этот пост
Сомнительные плюсы, если честно. Ни разу не сталкивался с таким и не планирую использовать это.

(112) а нафига обрамлять скобками блок, в котором присутствует только И?

(115) Для наглядности и простоты восприятия, скорее всего. Это пример автора, я добавил комментарии, чтобы показать нагляно описанной в (44).

(116) странная наглядность.
ИМХО, когда увеличивают количество скобок, все только сильней запутывается.

(117) Нет, в примере из (112) вполне наглядно взят в скобки отдельный блок. Для читаемости это наоборот удобнее

(116) Да, для этого и еще для единообразия. Не все знают приоритеты логических операций. Также бывает, что нужно заменить И на ИЛИ НЕ.

(118) любое сочетание И будет отдельным блоком и так.
А в результате могут появится монструозные конструкции с пятью закрывающими скобками в конце.
(119) Для единообразия так же их можно и не использовать...будет вполне себе единообразно. А тот, кто не знает приоритетов лог. операций, может посмотреть об этом в инете. Вот когда надо будет заменить, тогда скобки и поставить можно)

все понятно, но наркоманство какое-то

Выражение понятно через пару секунд; если привыкнуть - будет понятно мгновенно.

Однако считаю такое оформление кода некорректным - потому что есть code-style от 1с, по которому оформлены все типовые конфигурации. А так как работа идет в 90% случаев с типовыми, то именно стандартный стиль кода воспринимается быстрее всего, и код "нетипового" разработчика также будет воспринят быстрее, если он будет написан в соответствии со стандартами от 1с.

Примечательно, что методика (10) родилась в моей голове именно потому, что я запарился разбираться в сложных условиях не только своего но и чужого кода, в т.ч. "типового". Мне нужен был стиль записи логических выражений любой сложности, который позволит мне сразу (пусть и после некоторого привыкания) видеть всю структуру выражения "как на ладони", легко отлаживать, оптимизировать, менять порядок частей и комментировать их.

(123) ИМХО, в таком случае должно быть достаточно правильных отступов, не более того

(84) да, понимаю. думал меньше 10 секунд. мусором это считаю потому, никакой смысловой нагрузки данный кусок не несёт. весь код должен быть функциональным, это же не сочинение на свободную тему. считаю, что программист, читая код не должен думать, что вот это полезный код, а вот это воткнули для оформления, потому что кто-то не в силах без таких конструкций понять условие. короче, раздувательство кода.

Епт, только в (112) дошло зачем это нужно =)
Я теперь тоже буду так делать!

(123) Да ты вообще красавчик

(125) Ты не прав, код должен быть читаемым. по твоему нефиг оформлять отдельную функцию, если она используется однажды?

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

_

(0) Понятно, но нахрен не нужно. ИМХО.

(129) Смотря как на это посмотреть, действительно есть аналогия с отбором компоновщика: Ложь - "Группа ИЛИ", Истина - "Группа И", ну лично мне подход понравился

Понятно

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

(134) Как "Иначе" может заменить "Ложь Или А"? Или что ты имел ввиду?

Не мне не нужно, особо не сталкивался с такими выражениями в типовых

(10) Любые дополнительные члены в выражении требуют дополнительных мысленных усилий. Это не только усложняет понимание (пцсть ненамного), но и замедляет чтение кода и отвлекает от основной мысли, что более важно.

Поэтому, хоть система и-или дереви и неплоха, но я против ее широкого применения в таком виде. Я бы предложил заметить "Ложь ИЛИ" и "Истина И" на пробелы с сохранением форматирования.

на инфостарте выложили то же самое недавно
http://catalog.mista.ru/public/152801/

надо писать 1=1 или 0=1 :)

(138) То же самое по отношению к чему?

(0) Короче, Сережа, не парься - тебя не поняли - да и душ с ним.

Что ты хочешь от "простого Одинэсника".
Тут на нимфослете кто-то выдал за божественное откровение кривой отказ от рекурсивного вызова процедур, чему учат на первых курсах теории алгоритмов.

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

(139) Та же самая ссылка, которую ты дал в (10)  :)

(141) 5 лет все таки не укладывается в "недавно", это уверенное "давно" =)

(142) Надо читать как "недавно я наткнулся" )

Последнюю скобку тоже нужно переносить

В вопросе спрашивают знание составления логических выражений, а в теме разбирают как оформлять их. Так в чем вопрос то?

По поводу оформления: сходите в школу, универ там все уже давно придумано.
1)По поводу скобок - главное чтоб не было недостатка. а так хоть каждое условие выделяйте в скобки, нормальный человек легко это читает. (не говоря уже о том, что есть отладчик и я вообще не помню когда вникал что там в этих условиях написано)
2)"Тогда" не переносится на новую строку - что за новшества раздувать код и убивать читабельность?
3)Мастерить в виде дерева - вам делать нечего? Строчите быстрее и все. Сложные условия редко когда бывают из 5 блоков, а это читается мгновенно.

Чем люди только не занимаются, чтоб только ничего не делать :)

(145) Для меня "Тогда" на новой строке при сложном многострочном выражении — плюс к читабельности. Жаль, что автооступ в пофигураторе так не считает.

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

(147) Запутанными выглядят только сложные условия записанные без четкой системы. К тому же мы не только пишем сложные условия, но и читаем чужие. При чтении методика позволяет, не вникая в смысл произвольного сложного выражения, быстро переписать/переоформить в знакомый стиль.

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

зы. Сам использую подобное, но как, условно
Если СкорееВсегоЛожьНоНеФактИВообщеНаВсякийСлучай Тогда
Иначе
//чтототам
КонецЕсли;

(140) Понять-то поняли, только большинство считает что каких-то существенных преимуществ это не даёт. Вроде и так всё понятно, когда отформатированно.

Много секунд потратил, чтобы прочитать ветку и понять для чего эта дискуссия. Не понял )) Главное-чтобы код был рабочим. А сложные условия лучше сделать отдельной функцией с подробным комментарием.

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

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

(152) Тогда логичнее было бы выбрать вариант 2, а не 3.

(151) нотация или формализм записи сложных условий так, чтобы привычному к нотации человеку было легко это условие понять. С отступами и переносами, с автором и апологетами
ЗЫ В общем приятный конечно способ, но не без фанатизма

(152) Понятно - это когда понятно, а тут думать пришлось.))

(156) к (154)

(154) Если выбрал такой почерк, то придерживайся... Главное команда положительно относился. А то могут сказать, что Сережин код я не могу читать)))

(158) Какой почерк? В (154) я писал про нелогичный выбор варианта ответа в сообщении (152).

(0) Если все это для возможности простого коммента условия- то излишние сущности.

(160) Можешь обосновать? Покажи как ты комментируешь части сложных логических выражений.

Не забываем о следующих выражениях...
Если А Тогда
...
ИначеЕсли А=Ложь тогда
...
Иначе
...
КонецЕсли;

(162) Да, вечная им память во веки веков.

(161) Все гораздо проще)В данной ветке невозможно зарегистрироваться с другого устройства:регистрация пропадает.А Вы про сложные логические условия))

(161)
Вот такой пример, почти из типовой
<code>
Отчет =Новый Структура("Группировка,ДополнительныеПоля",1,1);
// 1 и типовой вариант
    
Если Отчет.Свойство("Группировка") И Отчет.Свойство("ДополнительныеПоля") Тогда
//ЗаполнитьДополнительныеПоляИзНастроек(Отчет.КомпоновщикНастроек, Отчет.ДополнительныеПоля, Отчет.Группировка);
        Сообщить("Истина!");
    КонецЕсли;

//2 вариант предлагаемый    
    Если Ложь
    ИЛИ    ( ИСТИНА
    И Отчет.Свойство("Группировка")
    И Отчет.Свойство("ДополнительныеПоля")
    )
    Тогда
        //ЗаполнитьДополнительныеПоляИзНастроек(Отчет.КомпоновщикНастроек, Отчет.ДополнительныеПоля, Отчет.Группировка);
        Сообщить("Истина!");
    КонецЕсли;
    
// 3 вариант легко получаемый из 1
    Если
        Отчет.Свойство("Группировка") И
        Отчет.Свойство("ДополнительныеПоля") Тогда
        //ЗаполнитьДополнительныеПоляИзНастроек(Отчет.КомпоновщикНастроек, Отчет.ДополнительныеПоля, Отчет.Группировка);
        Сообщить("Истина!");
    КонецЕсли;
    // 4 вариант для перфекционистов
    Если
        Отчет.Свойство("Группировка") И
        Отчет.Свойство("ДополнительныеПоля")
        Тогда
        //ЗаполнитьДополнительныеПоляИзНастроек(Отчет.КомпоновщикНастроек, Отчет.ДополнительныеПоля, Отчет.Группировка);
        Сообщить("Истина!");
    КонецЕсли;
    
</code>

(18) если до красоты дошло, то так красивее:

Если Ложь
ИЛИ Условие1
ИЛИ Условие2
ИЛИ и т.д.
Тогда
   ...
КонецЕсли;

(166) Так я и пишу, что для удобства комментов только и нужно.А читаемость лучше не становится.Смотрим (165) пример 2.Намного же хуже типового в примере1 (165)!

(165) Ты как то очень буквально понял методику. Зачем сверху делать группу-ИЛИ если внутри нее только один элемент? Это не моя методика =)

(167) Пример то не соответствует методике.

(169) Можно и два элемента написать с ИЛИ)
<code>
Отчет =Новый Структура("Группировка,ДополнительныеПоля",1,0);
     Состояние =Новый Структура("Включено,Ожидает",1,1);

    
    Если Ложь
    ИЛИ    ( ИСТИНА
    И Отчет.Свойство("Группировка")
    И Отчет.Свойство("ДополнительныеПоля")
    )
    ИЛИ    ( ИСТИНА
    И Состояние.Свойство("Включено")
    И Состояние.Свойство("Ожидает")
    )
    
    Тогда
        //ЗаполнитьДополнительныеПоляИзНастроек(Отчет.КомпоновщикНастроек, Отчет.ДополнительныеПоля, Отчет.Группировка);
        Сообщить("Истина - 2!");
    КонецЕсли;
</code>

(170) пример не удачен, от верхних Ложь можно избавиться.

(170) Теперь это подходит под мою методику, но ты забыл сравнить новое выражение с остальными вариантами. Случайно ли? =)

Легко

(171) А на синтаксическую ошибку не желаете нарваться?Перед ИЛИ должен быть операнд или вы первый элемент сложного ИЛИ без ИЛИ предлагаете? С Ложь все однообразно.

(172) Уже нет времени)...

(175) Ну мне тут нечем крыть. Признаю поражение.

Не понятно зачем упрощать логические выражения. Ради оптимизации или зачем? Оптимизация сомнительна, а восприятие ухудшается.

На самом деле плюс в возможности легкого комментирования частей выражения — это действительно плюс. Я постоянно использовал такой стиль, когда основным языком был SQL (был такой период). Кое-где это даже включалось в корпоративные стандарты. Но там это больше от бедности: в SQL ты не можешь, за редкими исключениями, оформить части выражения в виде функций, ввести дополнительные булевы переменные и т.д. А если и можешь, то не станешь этого делать по соображениям производительности.

Язык 1С конечно не верх выразительности, но от этих напастей в основном избавлен. Поэтому я за то, чтобы всячески упрощать монструозные многоуровневые много-вложенные логические конструкции, а не изобретать методы управления ими.

P.S. Кроме прочего, предложенная структура выражений упрощает кодогенерацию. Но в 1С это не актуально.

Вот смотрю и думаю почему табуляциями не выделены условия и "Тогда"? 1с же вроде выделяет, или вы как-то перенастраиваете табуляцию или это само собой разумеется, просто на это не отвлекаются? Т.е. должно быть так:

Если Ложь
    ИЛИ    ( ИСТИНА
    И Отчет.Свойство("Группировка")
    И Отчет.Свойство("ДополнительныеПоля")
    )
    ИЛИ    ( ИСТИНА
    И Состояние.Свойство("Включено")
    И Состояние.Свойство("Ожидает")
    )
    
    Тогда
    
    Сообщить("Истина - 2!");
    
КонецЕсли;

(179) Видимо ты под "табуляцией" имел ввиду "автоформтирование" и "автоотступ". Действительно, они не знают про такую методику. Поэтому приходится табуляции вручную расставлять.

(180)Получается alt+shift+f уже не попользоваться? Если да, то с этого надо было начинать придумывание своего стиля оформления. Одно дело табулировать вручную условие, а другое всю процедуру, в которой встречается данное условие.

(181) Автоформатированием я лично пользуюсь очень редко. Видимо уже привык. Автоформатирование будет ломать многие стили записи многострочных конструкций, т.к. не понимает их специфики.
В основном я страдаю от применения автоформатирования при вынесении метода (рефакторинг). В этом действии оно принудительное.

(182)"Автоформатирование будет ломать многие стили записи многострочных конструкций"
Я бы задумался о правильности их построения. Вы представляете какого будет программировать с вами в паре или после вас другим? Может быть ваши коллеги не зря возмущаются?

(183) В (10) я описал основные замечания коллег. Они не включали автоформатирование. Я и не утверждал, что коллеги зря возмущаются. Я хотел понять картину на большей выборке программистов.
Про многие стили многострочных конструкций я писал не только про свои. Даже в этой теме и в комментариях к моей статье приводились другие стили, которые тоже будут ломаться автоформатированием. Поэтому не стоит все валить на меня =)

(184)Я не валю, я рассуждаю.

А зачем вообще вы пишите выражения как в заголовке?

Непривычно, неудобно.

да