1 вариант:

ДатаПроверки = бла-бла-бла;
Отказ = Источник.Дата < ДатаПроверки;


2 вариант:

ДатаПроверки = бла-бла-бла;
Если Источник.Дата < ДатаПроверки Тогда
 Отказ = Истина;
КонецЕсли;


Какой вариант идеологически правильный?

Первый вариант некоторые могут не понять:)

в данном случае без разницы

Первый вариант только более читабельнее (и то только на мой взгляд)

(0) Первый короче (а стало быть, обозримей).
(1) Это их личные половые проблемы.

А почему ветка в LIFE, а не в v8?
По смыслу-то - вроде как тематическая.

второй проще воспринимается при чтении чужого кода.

(4) секция - работа.

1й лаконичный
2й структурный
если работаешь коллективно (твой код будут читать другие)
то 2й предпочтительнее

имхо

хз

Какой тип у переменной бла?

Первый красивее и понятней, второй для школоты

+(11)Хорошо бы перед этим проверить на тип (и заполненность)...
А то сразу ошибку в лоб получишь (в обоих случаях)

(13)+ и в попытку завернуть

(13) Если сразу получишь - то хорошо. Искать не надо будет.
А вот проверять на тип и заполненность или не надо - зависит от того, что было раньше.

(1) на кой черт тогда вообще в конфигуратор лезть, если не способен понять эту строчку

оно конечно, оно так - именно для школоты, вот тока как быть с этим ?


ДатаПроверки = бла-бла-бла;
Отказ = Источник.Дата < ДатаПроверки;
Попытка
   х = Отказ;
Исключение
   Сообщить("А нету переменной Отказ");
КонецПопытки;


(17) как так нету? ты не видишь суслика? Он же есть! проверка на равенство одинаковых типов всегда что-то да вернет

учиться тебе еще стим

думай еще о чем (17)

(18) Посмотри, какие варианты приведены в (0) :-)

поясните

(22) Варианты кода в (0) - не эквивалентны.
А все до (17) (включая меня) проявили себя дятлами.

второй дольше выполняется

(17) Ты пьяный?

(24) И тебе внимательно прочитать (17).

Или даже более простой пример:

Отказ = "ХЕР ВАМ";
// сюда подставить первый или второй варианты
Сообщить(Отказ);

(0)
имхо, много лишних строчек кода
сам стараюсь взять за правило писать короче (пусть и сложнее) -- в пределах разумного

(23) просто в (0) ТС не дописал ...ИНАЧЕ...

(0)ты походу шлангуешь всю работу против посидеть на мисте:))
Ну вот надо из пальца высосать и непременно запостить. Это наверное и есть МИСТОзависимость?

(26) Мы родом из семерко? Отказ - 99% переменная определенная всегда. 79% что процедура называтеся ПередЗаписью()

(27) Смотрим на тот код, который есть. Недописанного - его нет.

точно облака весь мозг поплющели

блин, народ. Я спросил про читабельность, а не про функциональность. Отказ в обработчиках записи и проведения всегда определен по умолчанию как ЛОЖЬ, харе придираться.
Вам "Источник" ни о чем не говорит?

(29) Не, просто не хрен надеяться на вероятность, если можно написать правильно.

Вот другой пример:

Отказ = Истина;
// здесь варианты кода из (0)

Переменная Отказ - определена. Вот только значение у неё будет несколько неожиданное, если Источник.Дата>=ДатаПроверки

(30) да никто не париться о правильности кода. говорим об оформлении же. можно привести и корректный пример кода, если этот не нравится оформленный по принципам в сабже

(32) Насчёт функциональности - см. (33).

(34) Ага. А потом ошибки ловим в хорошо оформленной программе.

и среди тех кто тут пренебрежно родом с семерки известен код из сабжа и его не равнозначность и неоднозначноть
и косяки текущиеся из варианта один

(33) переменная Отказ уже определена как ЛОЖЬ, тип Булево. Зачем её еще раз определять?

(37) Косяки или их отсутствие зависят не от варианта. И вариант 1 может быть правильным (в одной ситуации) и вариант 2 может быть правильным (в другой ситуации).

(36) ошибки мы всегда ловим, при любом раскладе. такова специфика

(37) Можно то же самое со знаками препинания? 5 раз прочитал - ни разу не понял.

(32) читабельность всегда была и будет лучше у второго варианта, ибо читают не только типоякрутойичиталкнута, но и те кто мысли строит ступенчато

(38) В (33) - по каким-то причинам установили Отказ в ИСТИНА (предыдущая проверка выявила какую-то хрень).
Вариант 1 вернёт его в ЛОЖЬ - что не есть гуд.

(40) Но можно уменьшить их количество.

(39) о чем и был пост (17)

(39) в каких ситуациях варианты 1 или 2 могут вызвать ошибку? Напоминаю, что речь идет о синтаксисе 8ке, обработчик ПередЗаписью, вызываемый в подписке на события

(43) да, есть три состояния булевых в языках без "жесткого" приведения

Ложь, Истина и еще третье Не ложь

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

(43)а что такого?? Ты имеешь ввиду, что после записи в пер. Отказ значения Истина надо всегда делать Возврат из процедуры?

(46) И я о нём же. Ситуация была приведена в (33).
Более подробно: предположим, что Источник.Дата>ДатаПроверки.
Изначально Отказ-ЛОЖЬ;

Если ЕстьДругиеКосякиПрепятствующиеЗаписи(Источник) Тогда
   Отказ = Истина;
КонецЕсли;

// а теперь твои варианты

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

(25) Поэтому и использую обычно первый вариант

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

(50) понял. Тогда, хм. первый вариант будет как-то так:

Отказ = Отказ ИЛИ Источник.Дата < ДатаПроверки;

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

конечно проще все впихать в одно, к слову
читаемо ?

... = Мин(Найти(ВРег(НазваниеИнтерфейса()),"АДМИНИСТРАТОР"),1)+Мин(Найти(ВРег(НазваниеНабораПрав()),"АДМИНИСТРАТОР")*2,2);

(53) А он и ответил - что правильность (а) или (б) зависит от.

(55) только давай не будем постить простыни. Понятно, что они никому не нужны. в (0) - не простыня

(54) Можно и так. И визуально этот код _может_ оказаться проще для чтения - из него понятно, что Отказ "накапливает" ошибки. А _может_ оказаться и сложнее.

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

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

(56)кароче ... я слишком пьян сегодня для высоких материй

Короче. Хватит пить !

(61)упал???? ... в день пограничка такое говорить пограничникам

бритва Оккама за

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

(62) пля скунки, точно простите подлеца пагранцы

С Днюхой вас Погранцы !

(62) Поздравляю !

(62) С праздником!

(55) мне кстати когда такой код встречается, я его не пытаюсь осмыслить как он написан. а начинаю эту строчку переписывать ступенчато.

(64)везет ... моя бухтит как пылесос ... жду когда спать уляжеться ... абы бутылку из заначки достать

(65),(66) и (67)спасибо

только первый вариант. а еще почаще использовать конструкцию ?(,,,).
а то иногда встречаешь:
если чтото=истина тогда
    делаем
иначе
    неделаем
конецесли

Глупое обсуждение...

(71) Бессмысленный вопрос - бессмысленное обсуждение.

(70) Не всегда эта конструкция бессмысленна. ЧтоТо может оказаться не определено - и в результате "Невозможно привести к типу Булево".

красивей

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

В данном случае предпочту 2-й

Вот не надо таких извращений.

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

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

Как там у Маконелла? "Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете"

(77) smaharbA показал в (17), что варианты 1 и 2 - НЕэквивалентны.
После этого спор о том, какой из них "красивее", IMHO, теряет смысл.

Если же речь идёт о выборе

ДатаПроверки = БлаБлаБла;
Отказ = Источник.Дата < ДатаПроверки;

и

ДатаПроверки = БлаБлаБла;
Если Источник.Дата<ДатаПроверки Тогда
   Отказ = Истина;
Иначе
   Отказ = Ложь;
КонецЕсли;

то, IMHO, далеко не факт, что второй вариант - нагляднее. (Чисто зрительно - условие (то есть, существенная часть) теряется в тексте).

(78)
Я и не именно об этом коде говорю, а вообще о "сокращения или хитрый ход ради красоты".
Да и возможно переменная Отказ была обнулена перед вызовом:)

Как-то правил код, где переменная была - булево. То есть цикл работал 2 раза, от Ложь к Истине.
Правил код, где ради производительности в цикл запихали эквивалент 500 строчек - одной строкой.
Чем проще - тем всегда лучше.

В (79) не "переменная была", а "переменная цикла была"

как правильно в условии писать?

если А=Б тогда....

или

если Б=А тогда...

очень, очень важный и спорный момент.

так же крайне интересно что быстрее работает.. какой вариант

(79) С тем, что "чем проще, тем лучше" (при неявном предположении "оба правильные", естественно) - спору нет.

(Кстати, пример с булевым параметром цикла - как бы не в одной из типовых 1С-овских видел).

Но прикол с примером в (0) - до smaharbA никто (в том числе и я) не заметил ошибки. Это уже говорит о том, насколько читабелен код. IMHO.

(81) Иногда и такое бывает полезно.
Скажем, в C++

if (x=0) // здесь ошибка, но компилятор в лучшем случае лишь предупредит

или

if (0=x) // и получаем кучу матов от компилятора

(81)
А какая разница?

А вообще, Маконнелл учит, что сначала проверяется самое очевидное условие:)

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

Краткость - сестра таланта!

монопенисуально

Чем непонятней, тем востребованней.

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

(89) В данном случае - переменная есть. Это вариант 1 из (0).
А теперь то же самое - но с вариантом 2 из (0).
И?

меньше буков

Ага, (55), (91)
Например, я довольно часто использую подобные конструкции.

   СписокВыбораКонтактногоЛица.ЗагрузитьЗначения(Запрос.Выполнить().Выгрузить().ВыгрузитьКолонку("ДолжностьФИО"));


Просто и со вкусом

(89) Такие глючки очень часто всплывали, например, на семерке - когда народ в ПриОткрытии писал выражение типа первого из (0), а потом жалился - почему это записанный документ после открытия всегда выдает запрос на сохранение, это же и в восьмерке осталось, так что с такими выражениями надо быть очень осторожным...

(92) ну, вот такие-то конструкции вредны. Хотя бы потому, что когда в этой строке происходит рантайм ошибка, ты хер поймешь, в каком месте ее искать. Так что "КЫР сестра ТЫЛ", но без фанатизма

(94) Не согласен. Конструкция полезная и популярная (правда, в более других языках - например, в C#). По сути - это то же самое последовательное выполнение вызовов методов, но без использования дополнительных переменных.
Отладчиком тут действительно пользоваться сложновато. Но это, скорее, проблемы создателей Отладчика. (IMHO, Отладчик как инструмент - нужен в редких случаях; если возникла ошибка - организовать (временно) условия для её анализа вполне возможно).

(90) а переменная в любом случае будет. В (17) она создается вне конструкции Если.

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

(92) очень трудно читается...

(96) Во всех случаях. Даже если переменной Отказ было присвоено значение - вариант 1 его изменяет _всегда_, вариант 2 - _иногда_. Соответственно, эти варианты работают по разному.
Какой из них правильный, а какой нет - зависит от того кода, который написан до этого места и после этого места.
Но один из них - всегда окажется неправильным.

(97) Можно переписать поудобнее:
СписокВыбораКонтактногоЛица.ЗагрузитьЗначения
   (Запрос
       .Выполнить()
       .Выгрузить()
       .ВыгрузитьКолонку("ДолжностьФИО")
   );

сотня

+(99) Это в некотором роде аналог конструкции with в паскале или VB.
(Ну а будь Конфигуратор помощнее - тут прекрасная возможность для оптимизации; более изощрённые компиляторы её и делают).

(98) я тоже самое и сказал.

(102) Не совсем то же самое. У Вас был перечень случаев, когда второй вариант неработоспособен. Но не обязательно будет работоспособен именно второй вариант (даже в указанных случаях). Кроме того, второй вариант может оказаться неработоспособным и в других случаях (когда переменная Отказ будет определена). И это будет ещё хуже: ошибку, связанную с неопределённой переменной ловить проще, чем ошибку, связанную с тем, что переменная _почему-то_ имеет не то значение, которое ожидалось.

Тут суть как раз в том, что сравниваются НЕэквивалентные конструкции. И говорить, какая из них лучше/хуже - бессмысленно.

А что лучше:


Если  Тогда
   Если  Тогда
       Если  Тогда
           Если  Тогда
               Если  Тогда
                   Если  Тогда
                       Если  Тогда
                           
                       КонецЕсли;
                   КонецЕсли;
               КонецЕсли;
           КонецЕсли;
       КонецЕсли;
   КонецЕсли;
КонецЕсли;

//или

Если  Тогда
   Продолжить;
КонецЕсли;
// и т.д.
?

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

В контексте того, что ловим Отказ - 2-ой вариант, а то первым можно и сбросить.

Наглядно, однозначно.

(103) не видя всего кода бессмысленно говорить об эквивалентности/не эквивалентности.
Если это кусок кода из процедуры ОбработкаПроведения(), ПередНачаломЗаботыСистемы() или еще какой системной процедуры с параметром Отказ, или произвольной процедуры/функции, гарантированно имеющей параметр/переменную Отказ с гарантированным булевым значением, то в обоих случаях получим абсолютно одинаковый результат.

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

(107) Отнюдь не одинаковый.
Пример - в (33). (Ранее установленное для Отказ значение Истина вариант 1 может сбросить в Ложь - что, скорее всего, неправильно).

+(108) Ну и разговор об эквивалентности/неэквивалентности фрагментов кода отнюдь не бессмысленен. Как раз наоборот - структурное программирование, которым пользуются уже "на автомате" как раз и построено на _отношениях_ между "входом" и "выходом" ("преобразователи предикатов").

(108) да нет же, в (0), при заранее существующей переменной Отказ с булевым значением, результаты кода будут абсолютно одинаковы, даже если в обоих изменить условие сравнения (но, разумеется, оставить его одинаковым в обоих вариантах)

(110) См. (33).
До выполнения этих фрагментов:
Отказ имеет значение Истина.
После выполнения варианта 1 Отказ получит значение ЛОЖЬ, если Источник.Дата>=ДатаПроверки.
После выполнения варианта 2 при том же условии Отказ будет по прежнему иметь значение Истина.

+(111) Иными словами, в случае, если это - обработчик события, то при варианте 1 если Источник.Дата>=ДатаПроверки, то результаты _предыдущих_ проверок будут в итоге проигнорированы - а это уже ошибка. Причём проявится, скорее всего, не сразу - со всеми вытекающими отсюда очень неприятными последствиями.

(111) а, ну да. Теперь я понял.

Во втором варианте не хватает Иначе...

я б так сделал: проверка отдельно, обработка результата проверки отдельно

Отказ = Не ДатаКорректна( Источник );

Функция ДатаКорректна( пИсточник )

Возврат пИсточник.Дата >= ПолучитьДатуБлаБлаБла();

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

+(115) чтобы не тыкали в (111) сразу говорю, что если проверок несколько, то все их выношу в отдельный метод, а присвоение отказу тока единажды происходит