Как вы пишете блочные операторы Если, Пока, Для, Попытка и т.п. если в теле всего один исполняемый оператора?

Вариант А:
Если А=Б Тогда Возврат; КонецЕсли;

Вариант Б:
Если А=Б Тогда
    Возврат;
КонецЕсли;

Б!

И руки Б отрывал Б тем, что делает Б иначе

)

(2) +1

Если Ложь Тогда Возврат; КонецЕсли;
но
Если А=Б Тогда
    Возврат;
КонецЕсли;

Если Ложь Тогда Возврат; КонецЕсли;

ИндусКодДетектед?

.

https://its.1c.ru/db/v8std#content:456:hdoc
"4. Тексты модулей оформляются по принципу "один оператор в одной строке". Наличие нескольких операторов допускается только для "однотипных" операторов присваивания"

. ибо не надо усложнять там где это нафиг не нужно
.
а то листаешь простыни по пять экранов, когда все может на 1-2 уместиться

Вариант А затрудняет чтение.

Особенная жесть, когда одновременно еще и на форматирование плюют.

В примере (0) только А.

(11) Строка короткая, чего там затруднять?

(13) вот и я про то же самое.
.
затрудняет чтение

если...
  если...
    если...
      если...
        если...

Упрощает чтение

Я бы написал Если А = Б Тогда Возврат КонецЕсли;

..

Я не Маяковский)

(13) Очень просто. При варианте Б работает единственное правило: открылась операторная скобка - ниже она будет закрыта.

Как бы, для единообразия.

какраз при комбинации разных вариантов будет затруднение чтения. Представь ты листаешь километровую простень, Видешь оператор "Если" не вдаваясь в подробности условия идешь вниз интуитивно ожидая "КонецЕсли, А там "Облом"

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

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

потому что когда я вижу блок - я ожидаю что там что-то сложное делается.. а тут хреняк! возврат (да еще без запяточки - повбывавбы). я наоборот напрягаюсь когда в блоке один оператора - сразу мысль что хотел сказать автор? не забыл ли он чтото еще написать кроме капитанаочевиднеости.

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

(0) ; здесь лишняя

    Если А=Б Тогда
        Возврат
    КонецЕсли;        



(25) она не нарушает парадигму

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

Вариант Б

(27) oslokot
Сообщений:     5495

(29) ого!!

мизда затягивает!

(30) Второй восклицательный знак здесь лишний =)

(23) Кому как удобнее писать.
Я например пишу
Если
КонецЕсли;
У уже потом условия и операторы внутри условия. Также и со скобками () открываю-закрываю, а уже потом в внутри скобок текст

(9) смотря что считать усложнением
по мне так вариант А это усложнение

(32) еще один Андреевич? ))

(32) но это не код!!

Кстати отсутствие пробелов в таких конструкциях А=Б вызывает отвращение и резкое снижение читаемости кода
Пишите с пробелами А = Б

Только так

(25) Необязательная <> лишняя.
1) единообразненько
2) проще рефакторить ибо 1)

(37) 1-Сники ленивые, А это нужно лишние клавиши жать...

Вариант А просто ужасен. Мало того, что он снижает читаемость кода, так ещё и вставит палки в колёса, когда "внезапно" логическая проверка усложнится, или в блоке добавится операторов

(35) Не. Великий князь, сын Императора =)

В клюшках я активно эксплуатировал вариант А для сокращения вертикальной простыни кода, а в снеговике это просто не нужно

Когда уже 1с:экзекутор внедрят

В первом варианте нельзя поставить брякпоинт на возврат. По сути - заподлянка для себя будущего.

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

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

(44) ЭКЗЕКУТОР
муж., лат. (исполнитель) чиновник при канцелярии и присутственом месте, на котором лежат полицейские и хозяйственые обязанности. Экзекуторский желудок все варит: и бумагу ест, и перья ест, чернила ест, и песок ест!

Толковый словарь Даля. В.И. Даль. 1863-1866.

(45) это в принципе единственное против варианта А.

(37) это ты скажи тем кто херачит простыни кода не отбивая смысловые блоки пустой строкой

вариант А используется для синтаксического мусора
если Ложь Тогда тСпр = Справочники.Спр.СоздатьЭлемент(); КонецЕсли;
(46) Камазы возят воду для роболарьков внутри мкад

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

(46) скорее всего это "удовольствие" достанется кому-то другому. Неужели сразу нельзя нормально сделать? Какой смысл экономить строки?

По-разному.
Если много условий "Если"  то А

(0) Вариант А только если 1С тупит и отрабатывает быстрее чем Б.
Очень редко, пару раз использовал за почти 10 лет в 1С.

(55) это не 1с тупит в варианте А, а попытка оптимизировать с помощью варианта А

*это не 1с тупит в варианте Б, а попытка оптимизировать с помощью варианта А

Ну я обычно совсем по другому делаю. Возврат один после блока Если. И инверсия условия:

Если НЕ А = Б Тогда
   //Код
КонецЕсли;

Возврат;

Не люблю я возвраты размазывать по процедуре

(58) > Если НЕ А = Б Тогда
А когда надо проверить на неравенство - пишешь "Если Не А <> Б Тогда"?

Подобный подход увеличивает вложенность кода на пустом месте.

(59) этих возвратов можно и десяток наполнить, лично мне не удобно и не нравится так.
Я <> тоже не использую. Либо = либо НЕ =

(60) Усложняем. "Если А > Б" или "Если Не А < Б"?

только так:

Если А = Б Тогда
    Возврат;
КонецЕсли;

(61) нет, операторы сравнения я использую. Не использую только оператор "<>"

(63) чем он плох?

(64) не знаю, не эстетичен. За то по коду можно определить кто из коллег его писал

Б. В 1С так принято. Вариант А для других языков

(64) это старый баян из 90х, не равно на 3 цикла дольше сравнения,

для 1с пофиг

(60) и эти люди не разрешают ковыряться в носу

(67) Вот жешь блин. А как же теперь почувстовать себя крутым и вообще не таким как все? =)

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

Для борьбы с этими пороками существуют другие методики. Например, разбивка кода на процедуры и функции.
Ведь, если мы вместо Б напишем А, простыне не перестанет быть простыней, а лапша лапшой.

(70) Потому что обсуждать особо-то и нечего?

Вариант А должен быть таким:
если а=б тогда возврат конецесли;

(58) "Не люблю я возвраты размазывать по процедуре"
а я наоборот. ибо по куску кода сразу должно быть понятно - он весь отработал и больше он ни с чем не связан или еще что-то будет...
.

Поэтому когда

Если чтото
  //тут всякий код
иначе
  //тут всякий код
КонецЕсли;

Возврат;

то я предпочитаю делать так:
Если чтото
  //тут всякий код
  Возврат;
КонецЕсли;

//тут всякий код
.

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

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

Я вот хз кому что там непривччно/тфяжело читать код. Может это болезно восьмерочников, которые только галочки расставляют, а чтение кода им мозг выламывает? ;-)
.
за 21 год в 1С я встретил всего один случай когда мне реально было тяжело читать код, пришлось адски напрягаться. это была какая-то обработка с Софтпоинта кажись. Код все хорошо был написан, прям по стандартам всяким. но читать его - я устал.
.
а все остальные коды - по крайней мере в клюшках - абсолютно пофиг - читал всё. затруднений не было.
единственно что на дух не переношу - так это лапшу без отсупов, без форматирования, без разбивки, смесь ключевых слов с прописной и со строчной, с какой-то тотальной невнятной логикой - короче адский говнокод.

(73) я предпочитаю всегда делать так

Функция а()
результат = Неопределено; // это всегда первый оператор
...
...
...
Возврат Результат; // это всегда последний оператор и единственный возврат во всей функции
КонецФункции

В обязательном порядке, только так:


Если А = Б Тогда

    Возврат;

КонецЕсли;

(76) т.е. результат, приняв единственное правильное значение может надеятся до конца функции(возврата) что он окажется не псиной, а царем зверей?)

(78) Нет, то что при любом ходе функции не будет ошибки - неинициированная переменная

(76) брехня..

чего, прям так и пишешь в коде ?


Функция вася (Параметры)
   результат = Неопределено; // это всегда первый оператор
   Если НЕ Параметры.Устраивают Тогда
       Результат = Неопределено;
   КонецЕсли;
   Если Пармаетры.НеВерные Тогда
       Результат = Неопределено;
   КонецЕсли;

   Если Параметры.ПолнаяЛажа Тогда
       Результат = Неопределено;
   Иначе
     ......остальной код....
     Результат = РассовоВерный;
   КонецЕсли;
   Возврат Результат;
КонецФункции


Заместо


Если НЕ Параметры.Устраивают Тогда
       Возврат Неопределено;
   КонецЕсли;


А если в вычислении функции будет кучка вложенных циклов, или рекурсивная функция, и при некотором условии нужно просто написать Возврат Нечто;, будешь результат = Нечто; писать и прерывать все циклы по условию, чтоб в конце функции сделать Возврат Результат ?
Сумневаюсь

(80) да, так, только без лишних условий.
(76) так же делаю, просто привычка и какой-то порядок

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

(83) ясно. Всё забываю проверить, как метка в снеговике работает, и куда она прыгать смогёт между модулями..

(80) я тоже так, точка возврата из функции должна быть одна

(85) + https://habr.com/ru/post/40841/

(86) ага.. и подавляющее большинство на том же хабре против такого подхода..один вход и один выход

Времена, когда использовали перфокарты, давно прошли. Экономить место ни к чему.
Чем больше комментариев, тем лучше. Код должен быть структурирован. И в (0) только

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

(86) у макконела в совершенном коде есть хороший обзор вариантов выходов с плюсами и минусами

Если всего один оператор, то допускается в одну строку и без скобок.

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

Нужно писать так, не помню точно как в 1с тернарный оператор, но суть такая:

    Результат = Параметры.Устраивают
        ? РассовоВерный
        : Неопределено;

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


(92) вариант хороший, т.к. уменьшает риски минимальными усилиями

(94) Но не лучший. Вообще переменные - зло. В нормальных языках от них отказываются.

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

Да, и условия стараюсь тоже не использовать. Ветвления в программе усложняют чтение и отладку.

ну да, а упоротые языки без переменных улучшают чтение)

(95) лучшее - враг хорошего
от лучших решений потом коллеги плеваться будут

вариант Б
патмушта:
1. для единообразия - чтоб моск при чтении не напрягался
2. для отладки
3. для будущих поколений себя любимого - а ну как потом придётся туда дописать что-то

(98) Не упоротые, а нормальные. Конечно улучшают.
(99) На то оно и лучшее, что все будут довольны.

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

(96) гордиться можно тем, что все внедрилось хорошо, код хорошо масштабируется и поддерживается
а то что там нет переменных и головоломки от этого, то это та самая упоротость, не имеющая отношения к качеству

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

Рекомендации языка 1с

Описано в ИТС

(76) я тоже так делаю, как тут лайки ставить :)

Быдлокодеров на кол!

(107) И как ты оформляешь десять последовательных проверок входных данных? "Лесенкой"?

(0)
Только Б

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

Функция а(п1, п2, п3, ... пN)
  результат = Неопределено; // это всегда первый оператор
  Если НЕ КонтрольВходныхПараметров(п1, п2, п3, ... пN) Тогда
    Возврат результат;
  КонецЕсли;
...
...
  Возврат Результат; // это всегда последний оператор и единственный возврат во всей функции
КонецФункции

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

(76)
Поддерживаю.

Но для простых функций делаю проще, чтобы кода было меньше:
Если <условие> Тогда
    Возврат 1;
Иначе
    Возврат 2;
КонецЕсли;

(112) Совсем опыта нет? :)
Это подойдет только в тривиальных функциях из учебников. В реальности функции делаются для частого использования и придется в десятках точек вызова не забывать проверять параметры, ну или вызывать еще одну функцию.

(114) :)) Ну да, конечно.

(114) в (112) правильно написано, функции и процедуры применяются не только для выделения повторяющегося кода, попробуйте тест написать для своей мегафункции и всё встанет на свои места

(116) И что должно встать на свои места?
Каждый день каждый использует эти мегафункции, простой пример: ОбработкаПроведения любого документа. Или по твоему это не таже самая простая функция без возврата значения?

(117) мозги встанут на свои места, если есть

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

хотя зачем я это тебе объясняю, оставайся быдлокодером, так спокойней

(113) Если можно написать без "Иначе" - лучше писать без "Иначе". Читается легче, рефакторить легче, меньше шансов ошибиться.

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

(118) Тяжело тебе малыш настоящему Дартарьяну, вокруг сплошное быдло :)

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

Б и только Б. Бесит когда в одну строчку. Что этим показывают? Свою "крутизну"?  Чушь все это.

Так отлаживаться проще и глазами видеть.

Если А=Б Тогда Возврат А; иначе Возврат Б; КонецЕсли;   - Пипец неудобно

(120) я тоже не понимаю каким образом тестирование отменяет проверку входных параметров :) я про это ничего не писал

Отказ = ?(ВсеПлохо,Истина,Ложь)

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

(126) Некоторые считают, что использование тернарных операторов такой-же дурной тон, как goto :)

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

Ну зачем же так фанатично. Нужна поверка - ну сделай вначале функции и точку выхода. Пусть будет две - в начале и в конце. Зло это в середине несколько выходов

(129) Достойная цель. Но не любой же ценой. Дроблением логики - да. Игрой синтаксисом - ересь.

Пишу "Если", <space>, <выбор варианта>, <написание условия>.
И всегда получается ...

Откуда вообще взялся вариант Б ?!

(133) в нормальных вузах так учат)

(129) хи-хи.
Вот смотри: УТ 11.4 ОбработкаПроведения РеализацииТоваровИУслуг (центровой документ для УТ однако):

ЗаказыСервер.ОтразитьЗаказыКлиентов(ДополнительныеСвойства, Движения, Отказ);
ЗапасыСервер.ОтразитьСвободныеОстатки(ДополнительныеСвойства, Движения, Отказ);
ЗапасыСервер.ОтразитьОбеспечениеЗаказов(ДополнительныеСвойства, Движения, Отказ);
ЗаказыСервер.ОтразитьТоварыКОтгрузке(ДополнительныеСвойства, Движения, Отказ);
ЗапасыСервер.ОтразитьТоварыНаСкладах(ДополнительныеСвойства, Движения, Отказ);
ЗапасыСервер.ОтразитьТоварыОрганизаций(ДополнительныеСвойства, Движения, Отказ);
ЗапасыСервер.ОтразитьТоварыОрганизацийКПередаче(ДополнительныеСвойства, Движения, Отказ);
Если ДополнительныеСвойства.Свойство("ЗаписыватьРезервыТоваровОрганизацийВместеСоВсеми")
    И ДополнительныеСвойства.ЗаписыватьРезервыТоваровОрганизацийВместеСоВсеми Тогда
    ЗапасыСервер.ОтразитьРезервыТоваровОрганизаций(ДополнительныеСвойства, Движения, Отказ);
КонецЕсли;
ЗапасыСервер.ОтразитьТоварыПереданныеНаКомиссию(ДополнительныеСвойства, Движения, Отказ);
ЗапасыСервер.ОтразитьУслугиКОформлениюОтчетовПринципалу(ДополнительныеСвойства, Движения, Отказ);
ЗапасыСервер.ОтразитьДатыПередачиТоваровНаКомиссию(ДополнительныеСвойства, Отказ);
ЗапасыСервер.ОтразитьТоварыКОформлениюОтчетовКомитента(ДополнительныеСвойства, Движения, Отказ);
ЗапасыСервер.ОтразитьОбеспечениеЗаказовРаботами(ДополнительныеСвойства, Движения, Отказ);
ДоходыИРасходыСервер.ОтразитьСебестоимостьТоваров(ДополнительныеСвойства, Движения, Отказ);
ДоходыИРасходыСервер.ОтразитьВыручкуИСебестоимостьПродаж(ДополнительныеСвойства, Движения, Отказ);
ВзаиморасчетыСервер.ОтразитьРасчетыСКлиентами(ДополнительныеСвойства, Движения, Отказ);
МногооборотнаяТараСервер.ОтразитьПереданнуюВозвратнуюТару(ДополнительныеСвойства, Движения, Отказ);    
СкладыСервер.ОтразитьДвиженияСерийТоваров(ДополнительныеСвойства, Движения, Отказ);
ВзаиморасчетыСервер.ОтразитьСуммыДокументаВВалютеРегл(ДополнительныеСвойства, Движения, Отказ);
ЗатратыСервер.ОтразитьМатериалыИРаботыВПроизводстве(ДополнительныеСвойства, Движения, Отказ);    
УчетНДСУП.СформироватьДвиженияВРегистры(ДополнительныеСвойства, Движения, Отказ);

Напомню, это обработка проведения, выполняется в транзакции. В каждой, В КАЖДОЙ из этих процедур первые 3 строки:

Таблица = ..как то получить таблицу.    
Если Отказ ИЛИ Таблица.Количество() = 0 Тогда
Возврат;
КонецЕсли;

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

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

Если Отказ Тогда
  Возврат;
КонецЕсли;

(135) подгорает? где я писал что мне не нравится проверка входного параметра?

(136) Я думаю головой, поэтому меня что-то "раздражает", ну то чем изволишь думать ты, что это что-то "подгорает" пусть у тебя расслабится :)
Так вот меня раздражает когда теоретики увидят учебный тривиальный пример и возводят его в догму. Посмотрят видосики создания функций возведеня в квадрат или даже вдруг станут гуру посмотрев пример рекурсии и начинают бросать постулаты.
Какая функция на один экран, если более-менее не тривиальный запрос только страниц на 5-10 строится.

(137) раздражает так сходи водички попей, всем как бы пофиг отчего у тебя подгорает

приведенный пример не ок но лучше чем если бы всё это было в одной функции

(137) Запрос сворачивается до одной строки, если что :))

Шаблоны же. Поэтому однотипно.

(139) да и вся функция тоже, при желании

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

(76) такой подход приводит к усложнению логических конструкций внутри функции и опасности возврата неверно инициализированного значения

(141) точно, а тут "если тогда" предлагают в три строки писать :)

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

(93) оператор ?() тоже зло, усложняющее восприятие кода и отладку. Никто его не переделывает в нормальное Если...Тогда, даже автор кода. Он непременно загниёт в уродливую длинную конструкцию с вложенными ?()

(114) не придётся, если декомпозиция кода выполнена по-человечески

(8)

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

(149) не только лишь все

(100) полностью поддерживаю и использую вариант Б из тех же соображений.

Люблю, когда в типовом коде несколько условий разнесены на разные строчки, т.е. не
"Если ПеременнаяСТипичноДлиннющимНазванием1 = 0 И ПеременнаяСДлиннющимНазванием1 <> ПеременнаяСДлиннющимНазванием2 Тогда", а
"Если ПеременнаяСТипичноДлиннющимНазванием1 = 0
    И ПеременнаяСДлиннющимНазванием1 <> ПеременнаяСДлиннющимНазванием2 Тогда"

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

(151) Это же разные вещи. Вариант А хорош для простых и коротких условий и операций, а вариант Б лучше для длинных.

(151) согласен, логика одна - повысить читабельность не в ущерб ничему

я аж бешусь, кто выбрал вариант А

(135)
>> Так ты и правда уверен что первой строкой в ОбработкаПроведения вот такой вещи это быдлячество:
>> Если Отказ Тогда
>>   Возврат;
>> КонецЕсли;

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

(152)+

(0) А где вариант: Я всегда пишу все процедуры и функции в одну строку?
Это еще компактнее и нагляднее.

(0) Потому что просто вставляется из шаблона.Минимум движений.

На разных строках, так больше денег заплатят. А если серьезно, то читается проще и не надо горизонтальный скроллбар надрачивать постоянно. А ещё неприятно, когда переменные типа и, й, к __строка1, ____число10 попадаются. Оторвал бы яи такому гению (у которого в IDE не работает автодополнение), после отладки подобного кода и попыток понять, чем отличается тз1 от тз2.

(143) такой подход дает 2 сильных преимущества

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

(114) +100500.Тоже удивился предложению проверТь параметры функции до ее вызова)))

Забыл проголосовать

Вообще по современным стандартам:

1. Возврат результата из функции должен быть один.
2. Инициализированные переменные и аргументы функции не переинициализировать.
3. Не использовать операторы ветвлений и переходов.
4. И конечно только чистые функции. Никакого морально устаревшего ООП.

Не всегда кажется это осуществимым, но если подумать, то на самом деле осуществить обычно можно.
Я щас не пропускаю пулл реквесты пока не исправят все эти моменты. И ведь исправляют!

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

Красивее, понятнее и читабельнее

(163) а дай ссылочку на "современные стандарты" где это описано

(166) Держи: (163)

(163) уже п.1 нет:

public static bool Any<TSource> (this System.Collections.Generic.IEnumerable<TSource> source)
{
  foreach(var item in source)
  {
    return true;
  }
  return false;
}

(167) пожалуйста аргументируйте, а то похоже на какой-то развод, кто сказал, что ООП морально устарел? Чем чисто функциональный подход дучше процедурного (только про замыкания не втирайте тут).

Давайте конкретику на стандарты или рекомендации серьезных компаний...

(168) foreach - плохой оператор.
Лучше так:

public static bool Any<TSource> (this System.Collections.Generic.IEnumerable<TSource> source)
{
    return source.some(item => item);
}

(170) так ведь ООП устарел, а ты используешь обьектную модель :)

сам себе противоречишь

(169) Если тебе ссылка на мисту не является авторитетной, то вот тебе ссылка на другой сайт в интернете:
https://medium.com/devschacht/glossary-of-modern-javascript-concepts-1198b24e8f56

(171) Объект при этом не изменяется. ООП наоборот, подразумевает изменение состояния объекта при выполнении над ним операций.

(172) JavaScript - это не язык а фуфел.... даже более ублюдочный чем 1с...

(169) Функциональный лучше тем, что замыкания.

(174) Ахахах! Шутник блин

(173) ООП - это 3 правила, и изменение объекта тут вообще ни причем...

(170) ну ты одно заменил другим, тогда расписывай реализацию some

Функциональный стиль прекрасен на определенном уровне абстрагирования, но когда приходится спуститься вниз к реальности, то как бы нет...

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

(176) почему шутник?

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

(177) Ладно, про ООП я не правильно написал. Использовать ООП можно, главное не создавать мутабельные объекты как это было принято раньше.

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

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

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

(180) ну вот начинается...

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

а так да, на определенном уровне абстракции мы красиво пишем:

var res = MyCollection.Where(x => x!=0).Select(x => 1.0/x).Sum();

(160) >> (и ты сможешь посмотреть результат до выхода из функции, в контексте его получения)

Только вот контекст будет уже изменен, так как переменную мог перезаписать несколько раз.

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

(182) мутабельность - это свойсто контекста в привязке к объекту. Ну а Контекст - это свойство среды исполнения... в том-же JS он определен клиентской 32 разрядной частью (очень криво реализованной в плане типов ineger и аналогов а так-же "песочницы"), собственно именно из-за "песочницы"  в JS и есть эта "мутабельность"

(188) Сообщите своё мнение на СелезнЁвку, мот прислушаются , а ?

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

(189) Ну а Москва - столица России. Что ты пытаешься доказать? Что мутабельность - это хорошо?

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

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

мутабельность это не ошибка а правило и если ты ему не следуешь получаешь ошибку...


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

1. Чистые функции должны принимать аргументы.
2. Одни и те же входные данные (аргументы) всегда произведут одинаковые выходные данные (вернут одинаковый результат).
3. Чистые функции основываются только на внутреннем состоянии и не изменяют внешнее (примечание: console.log изменяет глобальное состояние).
4. Чистые функции не производят побочных эффектов.
5. Чистые функции не могут вызывать нечистые функции.


------------------------------------------------------------------

то есть в этой концепции нельзя получать данные извне (например из SQL или COM или драйвера клавиатуры).

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

(193) На 1С может и не можем. Но на том же JS вполне можно, там все есть.

(194) Ты про иммутабельность или про чистые функции? Определись сначала что мы обсуждаем в данный момент.

Конечно в чистых функциях нельзя получать данные извне. На то они и чистые.

"извне" - это где?
параметры входные - это же извне?

(199) Кроме входных параметров.

(67) "не равно на 3 цикла дольше сравнения"
Непонял. И равенство и неравенство - это результат выполнения инструкции вычитания (в варианте cmp, без сохранения результата) и последующего условного перехода по флагу: нулевой или не нулевой результат (jz, jnz). Инструкции jz и jnz эквивалентны в плане быстродействия.

единообразие в приоритете

1.Вариант Б!
Ибо другие варианты  ересь! И за другие варианты гнать ссаными тряпками и сраной метлой в ассенизаторы из профессии.

(194) Шоколад не виноват. Пацан к успеху шёл, не получилось, не фартануло

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

(205) А чем процедура отличается от функции, по-вашему?

(206) Идеологически или технически? Идеологически очень многим. Функция - это значение. Процедура - это действие. Технически - зависит от языка и среды, в Си например всё функции, но Си это "переносимый ассемблер".

(206) https://ru.wikipedia.org/wiki/CQRS

Нужно делать структурируемый, удобно читаемый код

(207) не возражения ради. Просто уточнить.

Если Процедура - как действие, должна вернуть результат действия, она может же быть функцией?

так нагляднее

(163) >> 1. Возврат результата из функции должен быть один.

Этот стандарт нигде не соблюдается. Взять хотя бы код на java - там сплошь и рядом несколько возвратов из метода.

(174) ну так не используйте. отключите в своих браузерах запуск JavaScript в знак протеста против языка.

(212) Тут мои соседи сплошняком паркуются на газоне. Но это же не повод?
Запустил вчера проверку конфигурации (от 1с) на уг11.4 - 77 тысяч сообщений...
И что теперь - писать неправильно?

(210) Пусть возвращает, через изменения параметров

http://pics.wfido.ru/img/errs_2efu7.png

Уг 11.4.8.92, если что

(216) что за инструмент такой?
извините, я просто вчера с дерева слез )

(215) это же чертовски неудобно (

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

(207) "Функция - это значение" в математике?
Или откуда такие ограничения?

(220) Вероятно, травматические последствия знакомства с функциональными языками.

(220) потому что есть такая парадигма (208)

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

Я скорее за то, чтобы запретить процедурам возвращать значения, чем за то, чтобы запретить функциям менять состояние.

(218) АПК, вроде бы :)

(220) Потому что там каша парадгим, смесь функциональщины, императивности и ООП, приправленные желанием иметь свое неоспоримое мнение. Представь, что будет, когда они услышат про методы объекта, которые возвращают, например, код результата, и при этом изменяют состояние объекта? =)

(221) Математическое определение функции знаешь? А процедура - это просто именованная последовательность действий. Давайте не будем только упоминать язык Си и производные.

(225) А меня реально бесят функции с императивным именованием типа ПолучитьСуммуЗадолженностиКлиента(Клиент), вместо СуммаЗадолженностиКлиента(Клиент). К сожалению, такое даже в типовых постоянно встречается. Хотя в стандартах разработки от 1с это не приветствуется.

(229) в типовых таких дофига

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

ПолучитьСуммуЗадолженностиКлиента(Клиент)
РасчитатьСуммуЗадолженностиКлиента(Клиент)

а вот так уже не очень выглядит
СуммаЗадолженностиКлиента()
РасчитатьСуммуЗадолженностиКлиента(Клиент)


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

(231) 1с уже не согласна с тобой

(231) Вы не так понимаете. Я о том, когда пишут Задолженность=ПолучитьСуммуЗадолженностиКлиента(Клиент) - то есть именование функции, возвращающей значение, как действия. Если же пишут ПолучитьСуммуЗадолженностиКлиента(Клиент), имея в виду процедуру, которая куда-то там получает сумму задолженности - это нормально.

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

(231) > учитывать общую стилизацию

РассчитатьСуммуЗадолжности(Клиент, СуммаЗадолжности);
СуммаЗадолжности = СуммаЗадолженностиКлиента(Клиент);

Вот тебе и стилизация

(228) Так ты не ответил на мои вопросы

(229) а get.. set.. тебя тоже бесят?

(229) такие именования комфортно читаются, что немаловажно
например в тему из xUnitFor1C конструкция:
Ожидаем.Что("Некая строка").ИмеетДлину(12);

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

(229) "ПолучитьСуммуЗадолженностиКлиента(Клиент), вместо СуммаЗадолженностиКлиента(Клиент)."
это вообще бяка.
д.б. типа

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

(240) если это 8.3 там есть области для этого. в 7.7 наверное приходится извращаться.

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

(229) >> А меня реально бесят функции с императивным именованием типа ПолучитьСуммуЗадолженностиКлиента(Клиент), вместо СуммаЗадолженностиКлиента(Клиент).

Я пока в этом сомневаюсь. И тот вариант кажется верным, и другой, в разных ситуациях. Например, если у тебя переменная называется СуммаЗадолженностиКлиента, то по логике функция должна называться ПолучитьСуммуЗадолженностиКлиента. Вот так:

Перем СуммаЗадолженностиКлиента = ПолучитьСуммуЗадолженностиКлиента(Клиент);

Выглядит логично.

С другой стороны, функция с таким именем была бы удобна если забыть про промежуточную переменную:

Возврат СуммаЗадолженностиКлиента(Клиент);

Какой вариант не правильный, и почему?

(240) По идее вообще должно быть КлиентЗадолженностьСуммаПолучить(Клиент)

(240) чтобы они лежали рядом должно быть Клиент.СуммаЗадолженности()

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

Чотко

(244)(245) угу, а не тот трэш что есть...

(246) мы во всем блюдём меру. в секту функциональщиков пока не планируем

(246) требуется написать функцию "модуль числа". Как раз ее нет во встроенных функциях. Напиши чтобы она была чистой и без условий

(250) Мнэээ Макс(а,-а) не ?

(251) хорошо. Напиши тогда Максфй

(250) Модуль = Число(СтрЗаменить(Строка(Число),"-",""));
- не прокатит?

(253) часто так балуешься на проде?)

Вариант Б конечно же. Так удобно, и тому кто пишет и тому кто читает

(254) ну, модуль за кучу лет я давно не помню чтобы использовал ;-)
и чем тебе в принципе код не нравится? ;-) юзай (251) тогда

(250) Ох уж мне эти одинэсники...

Функция МодульЧисла(Число)

    Результат = Sqrt(Число * Число);
    Возврат Результат;
    
КонецФункции

Устроит

? =)

(250) На тебе еще вариант, без возможной потери точности.

Функция МодульЧисла(Число)
    
    Тест = Новый Соответствие;
    Тест.Вставить(Число, Истина);
    Тест.Вставить(-Число, Ложь);
    Тест.Вставить(Истина, -Число);
    Тест.Вставить(Ложь, Число);
    
    Результат = Тест[Тест[Число]];
    Возврат Результат;
    
КонецФункции

извращенцы

(257) грубо, есть недостатки

(259) тестировал хоть? Ох уж мне эти одинэсники...

(260) ну ты понял, кто пишет типовые на снеговике...

(262) Да, чой-то я с переходом от hashmap загнался и накосячил. Ну, кто ж виноват, что у 1С структуры данных такие корявые? =)

(263) ... написал автор рещения (253)

(264) вообще соответствие это индекс, а индекс это поиск, а поиск это условие

(264) ты накосячил, а виновата 1с

(266) А крутится все на процессоре, а там jnz разные, поэтому...

(268) тут то абстракция самая верхняя, сама 1с

(269) Ой, извини, пожалуйста, сейчас исправлюсь!

...а крутится все на байт-машине 1С, а там проверки разные, поэтому...

Я смотрю некоторые не только Макконнелла не читали, но и стандарты разработки 1с тоже

(271) если все читать - времени на продакшен не останется...

(250) Ну модуль числа и так никто не делает через условия. Есть много способов написать в функциональном стиле, тебе уже ответили. Можно даже чисто математически решить.
Придумай другую задачу

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

О, вот отличная иллюстрация использования паттерна "А" из опроса. А так же паттерна отрицания условия при сравнении.
Проверка заполнения реквизитов

Чувствуете запах?

(275) запах свежей полиграфии?

(275) а что не так? просто интересно.
чисто по логике - вроде норм, возвращает Ложь/Истина

.

(279) трэш какой-то

(277) Если не обращать внимание на вероятные ошибки, то как минимум было бы лучше так, ИМХО:

Процедура СообщитьОбОшибке(ТекстОшибки, ПроверяемоеПоле = Неопределено)

    Сообщение = Новый СообщениеПользователю;
    Сообщение.Текст = ТекстОшибки;
    Если ПроверяемоеПоле <> Неопределено Тогда
        Сообщение.Поле = ПроверяемоеПоле;
    КонецЕсли;
    Сообщение.Сообщить();
    
КонецФункции

Функция ПроверкаЗаполнения ()
    
    ПроверкаПройденаУспешно = Истина;

    // проверка суммы
    Если Сумма <= 99999 Тогда
        ПроверкаПройденаУспешно = Ложь;
        СообщитьОбОшибке("Неправильно заполнено", Сумма);
    КонецЕсли;
    
    // проверка периода
    Если ЗначениеЗаполнено(Период) Тогда
        ПроверкаПройденаУспешно = Ложь;
        СообщитьОбОшибке("Неправильно заполнено", Период);
    КонецЕсли;
    
    Возврат ПроверкаПройденаУспешно;
    
КонецФункции

Блин. У него вероятно еще и проверка инверсная. Вероятно, правильнее так:
Функция ПроверкаЗаполненияПройдена()
    
    ПроверкаПройденаУспешно = Истина;

    // проверка суммы
    Если Сумма > 99999 Тогда
        ПроверкаПройденаУспешно = Ложь;
        СообщитьОбОшибке("Неправильно заполнено", Сумма);
    КонецЕсли;
    
    // проверка периода
    Если НЕ ЗначениеЗаполнено(Период) Тогда
        ПроверкаПройденаУспешно = Ложь;
        СообщитьОбОшибке("Неправильно заполнено", Период);
    КонецЕсли;
    
    Возврат ПроверкаПройденаУспешно;
    
КонецФункции

(279) это уже усложнение кода получается. Отказ от условных операторов не должен быть самоцелью

(281) есть же библиотечные функции. Например, ОбщегоНазначенияКлиентСервер.СообщитьПользователю();

(275) И где там паттерн А?

(283) Решил что так нагляднее плюс не факт, что у автора кода БСП стоит.

(284) Иначе Возврат Истина;

Только Б. А в этом частном случае, думаю, лучше через тернарный ?(,,)

(286) и, конечно, использование этого паттерна сломало функцию?

(288) нет, не сломало

(288) Сделало невозможным отладку. Внутрь этой ветки нельзя поставить брекпоийт.

(282) > У него вероятно еще и проверка инверсная

Вооот. Понимание кода с первой попытки не проходит, приходится мучительно и неоднократно перечитывать. Паттерн отрицания условия во всей красе.

Естественно

(291)+
Это на самом деле из той же серии, что и использование отрицания в идентификаторах.

Если Не ТоварНеПродан(Номенклатура) Тогда
    // Успешного чтения

В 99.99% случаях вариант Б.
Без однострочных конструкций код понимается значительно быстрее.
Код после обускаторов тоже читается, но зачем делать обфускакию с своем коде?

Кто пользует вариант А - кхаб.
Пользователям ?() уже разогрели отдельный котел...

(295) > котел
В аду для интровертов нет отдельного котла (:

(296) это для хакатона..

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

Если ПустаяСтрока(ЧтотоСтрока)<>0 Тогда
  //тырыпыры

(293) Если Не ТоварНеПродан(Номенклатура)<>Неопределено Тогда