Приветствую всех.

Некоторое время назад довелось заниматься code review команды разработчиков.
Наткнулся на то, что в коллективе была принята методология использования вызова функций вместо процедур независимо от того, возвращает ли что-то данная функция или нет.

То есть код

РассчитатьЗадолженность(); //где РассчитатьЗадолженность() - функция

Повсеместно.

У кого какой опыт, кто какой методологии придерживается? Может быть я консервативен, но зачем использовать не по назначению конструкции?

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

Да ващще, пишут как хотят. Никакого уважения.

Shift+F9 не дружит с процедурами, иногда это очень нужно

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

(3) Плюс
(4) И тебе тоже

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

(4) Пусть в некоторых нет. Зачем в кучу смешивать всё? В каждом языке свои правила. Насчёт самого умного, предлагаю не хамить. Я ведь могу и ответить.

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

(5) В том числе и эта проблема имеет место быть сейчас. Повторю свой тезис: зачем мешать в кучу подходы к кодированию из разных языков?

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

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

(10) Зачем передавать отказ? Если отказ - процедура вообще не должна запускаться. Когда ты передаешь Отказ = Истина, процедура может поменять на Отказ = Ложь, что в корне неверно.

(11) Бредишь?

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

Процедура ОбработкаПроведения(Отказ, РежимПроведения)

    // Инициализация дополнительных свойств для проведения документа
    ПроведениеСервер.ИнициализироватьДополнительныеСвойстваДляПроведения(Ссылка, ДополнительныеСвойства, РежимПроведения);
    
    
    // Движения по денежным средствам.
    ДенежныеСредстваСервер.ОтразитьДенежныеСредстваУПодотчетныхЛиц(ДополнительныеСвойства, Движения, Отказ);
    ДенежныеСредстваСервер.ОтразитьДенежныеСредстваКСписаниюСПодотчетныхЛиц(ДополнительныеСвойства, Движения, Отказ);

...

КонецПроцедуры





И это вполне себе логично.

В каждой "внутренней" процедура в начале добавляешь проверку на отказ и всё.

Напиши мне этот же код только на функциях. Я даже за попкорном схожу.

Процедура это функция которая возвращает 0 значений.

Должно быть как в Golang, только функции которые возвращают от нуля до сколько надо значений, не обязательно одно.

Искусственное разделение на процедуры и функции глупо и только вносит путаницу и усложняет изучение и применение ЯП.

(13) а в чем проблема обозвать указанные Процедуры Функциями? Код работать не перестанет

(15) Зачем? Мне не надо ничего возвращать. Надо только передать.

(14) "Процедура это функция которая возвращает 0 значений"
Нет. Она не возвращает даже void, ЕВПОЧЯ

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

(14) "Должно быть как в Golang"
Вот только такого не надо.. Пожаааааалуйста...

(18) Так и запишем. Лисп, Скала и Хаскель - исключительно говнокодные языки ))

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

(13) Примерно так:

Функция ОбработкаПроведения(РежимПроведения)

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

    ПроведениеСервер.ИнициализироватьДополнительныеСвойстваДляПроведения(Ссылка, ДополнительныеСвойства, РежимПроведения);
    
    
    // Движения по денежным средствам.

    Если ДенежныеСредстваСервер.ОтразитьДенежныеСредстваУПодотчетныхЛиц(ДополнительныеСвойства, Движения)
        И ДенежныеСредстваСервер.ОтразитьДенежныеСредстваКСписаниюСПодотчетныхЛиц(ДополнительныеСвойства, Движения) Тогда

        ...

    Иначе
        ....
        Возврат Истина;
    КонецЕсли

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


Логика гораздо понятнее.

(14) Опять 25. Зачем как где-то? У Golang цели другие.

И следует адекватно называть функции. Не должно быть императивного именования. Функция это не действие и не команда.

То есть, не надо писать "Сумма=ПолучитьЗадолженностьКонтрагента(Контр)", а надо писать "Сумма=ЗадолженностьКонтрагента(Контр)"

(22) Функцию с обработкой данных в условие?.... Да ты чо? Вот это точно моветон.

Поддержу (4).
Использование в качестве процедур, функций очень удобно, хотя и заставляет думать о том, как использовать результаты :-)

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

(25) Зато все понятно, и код успешной обработки отделен от кода обработки особой ситуации.

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

(20) Давайте еще регулярные выражения вспомним и будем весь код писать в одну строку. Просто не нужно с других языков тащить в 1С стили оформления кода. У 1С есть свои стандарты разработки.
В любом другом языке пишите как нравится.

(28) В каком месте я забыл? Во-первых, это типовой код, во-вторых, это стандартная процедура проведения, там не проверяют обычно отказ перед выполнением.

(28) Опять же, когда у тебя в функции произойдёт исключение, у тебя завалится твоё условие, потому что функция вернет экспешн, не дойдя до точки Возврат <чё-то там>.

(30) Там может отказ уже истина на входе был. Предлагаешь идти "вверх", чтобы точно узнать - надо тебе проверять это значение или нет? Это такой источник ошибок... не надо забывать, что то, что "наверху" вообще другой отдел может разрабатывать.

(31) Необработанное исключение завалит и код в (13). Обработанное исключение вернет то, что надо.

(32) Откуда в обработке проведения сверху может придти отказ? Это же не подписка.

(32) Я не предлагал. Повторяю, в каждой процедуре указана проверка на Отказ = ИСТИНА. Я привёл пример типового кода.

Ты со своим подходом переписываешь все типовые процедуры ОбработкаПроведения? Если нет, тогда не надо лить тут воду.

(33) +1

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

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

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

(37) Проведение в транзакции выполняется. Эксепшн откатывает движения. По крайней мере у меня не было описанных тобой проблем.

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

(39) Вообще наверное везде все к примитивным типам данных всегда сводится

(38) Движения остаются в коллекции движений у объекта документа (она же не в транзакции). А 1С если в таблице движений в доп. параметрах 0 строк, ничего не делают (в т.ч. не очищают движения от предыдущей попытки). Регулярно ловлю такую фигню. Она вылезает именно если до этого движения были, а потом пользователь поменял документ так, что движения по этому регистру пропали.

(39) Тут дошли слухи, что некоторые нестрогую типизацию тупейшей хренью считают... впрочем, это характеризует именно их.

функция которая ничего не возвращает это обман.
Ненаписание слова "Знач" это тоже обман.
Не надо никого обманывать.

(43) "Ненаписание слова "Знач" это тоже обман" // Для большинства коллекций значений это вредно, иногда приходится жертвовать этим маркером входящего параметра

(19) >Вот только такого не надо.. Пожаааааалуйста...

Ха в Голанге еще и массивов со списками можно сказать нетути )) Зато там есть слайсы!

И да 1Сные массивы и прочие структуры работают на слайсах.

(24) Кто сказал?
Тру языки пестрят функциями set и get.
ЗадолженностьКонтрагента - что задолженность контрагента. Получить или установить?

(46) https://its.1c.ru/db/v8std#content:647:hdoc

(47) это в 1С придумали, что процедура - это метод, а функция - это свойство?

(47) исходя из п 4 и п 5, если вдруг заходим, чтобы процедура ЗагрузкаКонтрагента начала возвращать результат этой загрузки и переделаем ее в функцию, то Функция ЗагрузитьКонтрагента будет уже неверным, верно будет Функция ЗагрузкаКонтрагента.
Т.е. Процедура ЗагрузитьКонтрагента - это верно, а Функция ЗагрузитьКонтрагента - это неверно?
Смахивает на бред. Учитывая, что Процедура это и есть Функция фактически то.

(13)
Процедура ОбработкаПроведения(Отказ, РежимПроведения)

    // Инициализация дополнительных свойств для проведения документа
ПроведениеВыполнено=Ложь;
   Если ПроведениеСервер.ИнициализироватьДополнительныеСвойстваДляПроведения(Ссылка, ДополнительныеСвойства, РежимПроведения) Тогда
    
    
    // Движения по денежным средствам.

    Если ДенежныеСредстваСервер.ОтразитьДенежныеСредстваУПодотчетныхЛиц(ДополнительныеСвойства, Движения) Тогда
     Если ДенежныеСредстваСервер.ОтразитьДенежныеСредстваКСписаниюСПодотчетныхЛиц(ДополнительныеСвойства, Движения) Тогда

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

КонецПроцедуры

(46) "ЗадолженностьКонтрагента - что задолженность контрагента. Получить или установить?"
Это _значение_, а не _действие_". Вы в математических формулах тоже будете писать ПолучитьСинус(x)?

(49) "Смахивает на бред. Учитывая, что Процедура это и есть Функция фактически то."
Сишник детектед!)

(46) Есть отдельный холивар на тему "свойства это хорошо или плохо".

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

Функция СделатьДело()

МассивОшибок = Новый Массив;

Попытка

РезультатОперации = Сделать1();

Исключение

РезультатОперации = Неопределено;

МассивОшибок.Добавить("Не шмогла " + КраткоеОписаниеОшибки(ИнформацияОбОшибке()));

КонецПопытки

Результат = Новый Структура;

Результат.Вставить("ОперацияУспешна", МассивОшибок.Количество() = 0);
Результат.Вставить("МассивОшибок", МассивОшибок);
Результат.Вставить("РезультатОперации", РезультатОперации);

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

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

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

(54)

В приведенном примере годное исключение превращено в мерзкий возврат какого-то омнища.

А если эту функцию вызывает другая, а ту ещё одна. Они должны этот шлак возвращать до самой верхней функции?

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

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

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

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

(58) Жаль что приходится работать с крупными программными системами?

(60) крупная - это ERP что-ли?

(52) "Сишник детектед!)"

Учитывая, что платформа писана на плюсах, то ваша Процедура ЗагрузитьКонтрагента выполняется в контексте какой-нибудь

void foo() {
//bla bla bla
return;
}

не надо тешить себя иллюзиями )

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

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

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

И да, инфа о том что 50 сообщений ок, а 50 не ок - это не ошибка, такое вернуть не зашквар, хотя такому место обычно в out параметре процедуры. Как отличить одно от другого? Не ошибку можно проигнорировать.

А вот возврат от процедуры в примере (54) это самая что ни есть ошибка и её место в исключении. Потому что завтра придет другой расп**й и на этот возврат тупо забьет. Что получится в итоге? Пользователь не получит ужасного сообщения об ошибке! Функция тупо не сработает. А это гораздо хуже.

(65) Слился до перехода на личности? Засчитано. Спускайте воду! Следующий!

(67) переход на личности у тебя был, придурок.

(68) Я писал про абстрактного тупого дятла, но ты сам себя спалил.

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

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

(70) а почему не писать в регистр сведений? это я чисто так спросил, не бросайтесь камнями)))

(72) пробовали, по скорости не удовлетворило, т. к. процесс записи в БД оказался более затратен на объемах в 60 млн. записей. тем более - это лог, зачем его хранить в базе? а как потом такие объемы быстро обрабатывать?
в лог выполнения должна писать не только 1С, а еще несколько микросервисов.
тут либо в файл, либо помойка в брокере сообщений, которая парсится elastic search'ем.

в чем, кроме идейного, разделение между процедурой и функцией?
или это как спор, с какой стороны сосиску есть?
или автор - фузиновец? )

(70) Я уже написал. Ошибки поднимаются исключениями до уровня когда ошибка превращается в запись лога. Записи лога уже не являющиеся ошибками поднимаются в out параметрах процедур до уровня когда их можно писать куда нужно (а можно и не писать - на функциональность не повлияет). Пример в (54) ничего общего с этим не имеет. В нем нормальное исключение т.е. ошибка заметается под ковер.

(73) так я понял вы пишите только ошибки. Это на 60 лямов записей столько ошибок что запись в регистр тормозит?

(76) нет, там кроме ошибок еще информационные сообщения.

(62) Это неважно, на чём написана платформа. В конце концов всё упирается в машинные коды и регистры процессора. И это не повод утверждать, что call/ret и функция это одно и то же)

(75) ну тут такая тема, что так и делается, анализируется ОперацияУспешна, тот же параметр функции, который также можно упустить в дереве вызовов до верха.

(79) ХЗ. Моё имхо - так цывильнее:

Процедура ВыполнитьВсеДействия(Лог)

Пока Надо Цикл
Попытка
СделатьДело();  
Исключение
Лог.Добавить(ОписаниеОшибки());  //превращаем ошибку в лог на этом уровне - ниже только исключения.
КонецПопытки;

КонецПроцедуры


Процедура СделатьДело()

Попытка
Дело1(); // разворот в кучу процедур, в разных местах могут возникнуть исключения
Исключение
ВызватьИсключение "Понятный коммент об ошибке если уж очень хочется. " + ОписаниеОшибки();
КонецПопытики;

КонецПроцедуры;

и никаких флагов "успешно/неуспешно". Только успех!

1) Процедуры не нужны.
2) Функция должна возвращать структуру.
3) Скорее всего функция должна принимать структуру, но это не точно.

(81) со всем согласен, кроме 1. процедуры для красоты ))

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

(83) и не слишком ли много "попыток" в примере?

(81) (82) "Процедуры не нужны" и "Функция должна возвращать структуру" немного противоречивые утверждения. Допустим, мы отказались от процедур и действия делаем тоже функцией ЗаписатьРеквизит(ДокументОбъект,ИмяРеквизита,ЗначениеРеквизита). Мы записали этот реквизит, что функция должна впихнуть в структуру и зачем ее возвращать?

(81) void main(void) ?

(81) ++
Структура возврата всегда должна содержать 2 или 3 элемента:
Результат - Булево
ОписаниеОшибки - Строка
КодОшибки - Число (если в дальнейшем планируется как то по разному обрабатывать ошибку а не просто выпулить ее на экран)

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

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

(88) для отладки

(88) чтобы по цепочке вызовов не перекидывать ошибку

(89) а мне не нужен результат записи.  А ошибки не проще в самой процедуре записи обработать чем в каждом ее вызове обрабатывать?

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

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

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

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

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

Функция и процедура это как абстрактный прообраз двух главных инструментов прораба на стройке: "Дай сюда" и "На, сделай". Как можно их путать...

(98) в некоторых языках нет разницы, у них все процедуры -> функции

(0) "в коллективе была принята методология использования вызова функций вместо процедур": раз была принята - значит есть какая-то причина. Вот и узнай у того, кто принял. А раз стандарт принят, его используют не только разрабы, но и те, кто занимаются code review.

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

(97) Эти абстракции позволяют писать красивый понятный код, если им следовать. А иначе получается горький катаклизм, когда проще всё написать с нуля, чем разобраться.
(100) Использование микроскопа в качестве молотка допускается в большинстве случаев.

(99) Там просто работники тупые и понимают только одну команду прораба. В 1С поумнее :))

(101) "Использование микроскопа в качестве молотка" - аналогия неуместна.

(99) Просто некоторые из них возвращают требуемый и значимый результат, а некоторые формальность или void. Т.е. деление присутствует, явно или нет.

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

*можно сделать два действия

(104) Нельзя определять меньшее через большее. Это как определение точки через круг с радиусом 0, когда круг сам по себе определяется как множество точек. Функцию в языках программирования можно определять как процедуру, возвращающую значение. Но не наоборот. То, что в популярном переносимом ассемблере все подпрограммы обозвали "функциями", ничего не значит в общем.

1C-LISP

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

(100) Так было решено просто так, без обоснования. Потому что так захотелось. Специальных тестирований не проводилось. Подход в разработке "все, что не запрещено, разрешено" - хреновый подход. Тем более без тестирования. Нет никаких гарантий, что в случае высоконагруженных систем "всё, что не запрещено" будет обеспечивать тебе ту же производительность, что и предлагаемые методикой конструкции. Это как минимум.

(110) "Так было решено просто так, без обоснования"
Значит, вы там все малоквалифицированные кодеры. Я, когда мне показывают свод коде-стайла, всегда спрашиваю, если с чем не согласен, чем это вызвано.
И три раза ))) стайл меняли.

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

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

(39) "Тот кто мыслит строками может такое выдумать. Кто мыслит объектами и взаимодействиями".
Что за строки? И вообще, разверни

(0) главное чтобы за код ревью заплатили .

(112) как это не возвращает ...а  через параметр процедуры ?

(115) это уже побочные эффекты, сама то ничего не возвращает

(115) Ну так функция тоже так может, но может еще и сама что-то вернуть)

(117) значит в (0) все норм.

(111) Я бы попросил не делать необоснованных выводов и нелицеприятных идентификаций не зная всей ситуации. Но ты всё равно не послушаешь))

Самое адекватное объяснение ИМХО в (51)

(0) Я другую крайность видел, только процедуры, функции только для локальных проверок, остальное глобальные структуры и объекты.

1. одни функции
2. функция без возврата в окончании, возвращают 0
3. булевы - ложь и истина тоже заменить на 0 и иное, тоесть Ложь это константа =1
4.  код в функцию разрешать вставлять как текст динамически, тоесть код может сам вписываться в основной код, и получать его как func.text,
5. прикладным обьектам разрешать копировать функции от одного к другому;
например;
кодф=Справочник.ТМЦ.Функция.Расчет.Текст;
далее программно ...изменяем/удаляем строки и присваиваем текст функции другому обьекту, это простейшая замена наследованию в 1с))

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

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

(88) как ты тогда борешься с многократными ошибками в транзакции?

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

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

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

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

(128) если это логически неделимый объект/список, то всё нормально. А если функция одновременно вернула мёд, говно и пчёл, то это автоматом говнокод

(0) я не имею ничего против, если вся команда так делает. Просто локальная особенность соглашения о кодировании. Нормальная тема.

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

(130) "мёд, говно и пчёлы" (с) - это вообще-то тоже логически очень слаборазделимый объект...

(131) Эта тема нормальна, когда ей имеется логическое объяснение. А не просто "у нас так принято".
В таком случае вспоминается байка про клетку с обезъянами и бананами

(134) а какое логическое объяснение отказа от функции в пользу процедуры, когда не надо возвращать результат?

(129) Последовательна цепочка действий

(135) Не так. Как логически объяснить применение функций там, где не надо возвращать значение?

(137) Сейчас не надо, а завтра уже надо. Повышенная устойчивость к рефакторингу.

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

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

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

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

(88) "Кстати, за всю практику не пользовал ВызватьИсключение() - я вообще не понимаю, нахрена в правильно спроектированной системе оно нужно"
Ну типа пример

Функция ГлавноеСвойство(Объект)

    Результат = Неопределено;

    Если Объект.Пол = "Мужык" Тогда
        Результат = "Сила"
    ИначеЕсли Объект.Пол = "Баба" Тогда
        Результат = "Красота"
    КонецЕсли;

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

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

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


Функция ГлавноеСвойство(Объект)

    Результат = Неопределено;

    Если Объект.Пол = "Мужык" Тогда
        Результат = "Сила"
    ИначеЕсли Объект.Пол = "Баба" Тогда
        Результат = "Красота"
    Иначе
        ВызватьИсключение "Неизвестный пол объекта!";
    КонецЕсли;

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

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

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

(143) или чтобы эскалировать исключение после его обработки https://its.1c.ru/db/v8std#content:499:hdoc

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

и когда мы в процедуру передаем флаг "отказ",то это можно рассматривать,как возвращаемое значение

а есть ли разница?
Процедура ЧтоТоСделать(Результат,Параметры)
Функция РезультатВыполненияЧегоТо(Параметры)

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

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

а еще функцию можно вызвать из табло

(145) > а есть ли разница?
Конечно есть - функция создает новую сущность - возвращаемое значение, а в процедуре ты меняешь окружение, и еще неизвестно насколько качественно.

(147) Это где такое написано?

(147) Я достаточно давно уже пишу вот так:

Функция МояФункция(ВходящийПараметр1)

   РезультатФункции = новый Структура();
   РезультатФункции.Вставить("ВыполненоУспешно", Истина);
   РезультатФункции.Вставить("ВыходнойПараметр1", Неопределено); //При необходимости
   РезультатФункции.Вставить("ВыходнойПараметр2", Неопределено); //При необходимости

   Попытка
      ...
   Исключение
      РезультатФункции.ВыполненоУспешно = Ложь;
   КонецПопытки

   Возврат РезультатФункции;

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

(148) что именно написано? я говорю по факту. C чем конкретно ты не согласен?

(150) "функция создает новую сущность" - с эти не согласен. Например:


...

Если ВсеОбязательныеПоляЗаполнены() = Истина Тогда

Иначе
  Сообщить("Иди Заполняй как надо");
КонецЕсли;

...

Здесь "ВсеОбязательныеПоляЗаполнены()" это функция, которая никаких новых сущностей не создает, а просто выполняется проверка корректности заполнения данных. И в результате возвращается "истина\ложь".

(151) "Если ВсеОбязательныеПоляЗаполнены() = Истина Тогда" - Какой-то семёрочный код. Правильно писать так: "Если ВсеОбязательныеПоляЗаполнены() Тогда"

(151) возвращаемое значение - это и есть новая сущность, ты с ним и работаешь в блоке Если

*

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

(155) Не правильнее. В данном случае всё, что не истина  - не подходит. Зачем лишняя операция сравнения?

(156) А если ВсеОбязательныеПоляЗаполнены() вернёт неопределено, как твоё условие сработает? ))

(155) если вернется не истина, то это явный баг в функции и сравнением с "Истина" этот баг будет скрываться

(157) Не поверишь, но точно так же :))

(149) А текст исключения куда деваешь?

+(159) Точнее будет ошибка. Но не вижу смысла закладывать избыточную проверку на быдлокодерство.

(161) это называется безопасный код.
код не должен падать... никогда

(162) этот код с багом не будет падать даже на этапе отладки

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

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

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

(160) Как правило туда же, в структуру возврата. Добавляю в "РезультатФункции" такие поля:

"ТекстОшибки" - текстовка из "ОписаниеОшибки()"
"КодОшибки"   - некое число, уникальное в рамках функции (1,2,3...). Это для простоты отладки и быстрого понимания где именно "пало". Т.к. Может быть много вложенных Попыток и разных сусловий приводящих к "РезультатФункции.ВыполненоУспешно = ложь"

(166) значит концепция написания безопасного кода просто далека от тебя

(165) вот и проверяем на  истину ..но явно и перепроверяя движок

(165) вот если бы в 1с была статическая типизация

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

(168) Да. Концепция бессмысленного пожирания лишних ресурсов далека от меня. Поэтому избыточные операции стараюсь не использовать.

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

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

(170) Чем мешает её отсутствие написать функцию, которая гарантированно возвратит булево? Неужели это искусство утеряно новым поколением программистов?

(172) Готов поспорит про "бессмысленного пожирания лишних ресурсов". Именно для данного прмиера.

Давай замеры производителности сделаем, :)

(173) Там, где производительность не важна, соглашусь, что можно писать так, что будет работать дольше, зато с кучей проверок "от дурака". Но истина, как обычно, посередине - нужен баланс, и ВСЕГДА вставлять проверки от дурака даже там, где они не нужны - имхо, лишнее.

(174) а вопрос не в том что она возвращает ..а в  том
Что несмотря на то что движок неявно может проверить результат

Лучша бааа ещё разок проверить через равно

(175) Ты хочешь сказать, что две последовательные операции сравнения будут работать так же, как и одна?

(169) проверка движка будет,как раз, если не сравнивать с булево, иначе в чем проверка заключается?

(177) А для функции ЗначениеЗаполнено() ты тоже пишешь
"Если ЗначениеЗаполнено(ХХХ) = Истина Тогда" ?

Вопрос и к mzelensky

(177) Что значит, неявно? Конструкция Если <Выражение> Тогда вполне себе явно проверяет результат на значение Истина.
Так зачем ещё раз ОТДЕЛЬНО проверять результат функции, если мы знаем, что результат должен быть типа булево?

(180) значение заполнено это функция  движка...
Но можно  и ее проверить .. но будем доверять

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

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

Хреновы спорщики так кто нить покажет хоть один пример (хотя бы в 1С) где требуется именно Процедура!
И нельзя обойтись функцией...

(180) Нет. Это встроенная функция. В нее "шаловливые ручонки" влезть не могут. Ее я не проверяю

(185) НоменклатураПриИзменении()  что вернешь?

Как часто вы используете Goto в смысле Перейти ?

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

(186) Ну о чем я и говорил. Смотри (183) и (184).

(186) Т.е. возврат чего-то кроме булева это результат "шаловливых ручонок". Абсолютно согласен.

(187) Еще раз. НИЧЕГО НЕ ВЕРНУ!

Вместо
Ном = НоменклатураПриИзменении();

Просто напишу
НоменклатураПриИзменении();

И все.

(183) Именно. Правило - "Доверяй, но проверяй".

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

Тем более в плане производительности тут еще вопрос...что быстрее

(192) По мне, надо больше доверять людЯм :))

(191) Чем
функция, возвращающая void, отличается от процедуры?
кроме того, что процедура явно говорит, что от неё возвращаемого значения ждать не следует?

(191) Т.е. использовать её собираешься исключительно как процедуру, но при этом назвать процедурой не хотим.

(193) https://i.ytimg.com/vi/-hu0-lQORcs/hqdefault.jpg

+(193) Но т.к. я начинал программировать, когда каждый байт оперативы приходилось экономить, и от количества операций напрямую зависела скорость программы, то уже на автомате стараюсь не использовать избыточные операторы. Хотя в отдельных случаях соглашусь, это необходимо.

(149) зачем так услажнять? Пардон, но это не защитное программирование, а заSHITное программирование

(194) А вот тут нужна строгая типизация и средства интерпретатора/компилятора должны проверять что функция ничего не возвращает а кто то хочет получить и код не запустится!

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

(193) После этих слов я начинаю НЕ доверЯть лЮдЯм еще больше!

(195) Ты в курсе что у ненцев и прочих чукчей есть от 10 до 40 различных названий разного вида снега?

Ну там пухляк и т.д.

(199) В паскакале типизация строжей некуда. А всё равно разделили...

процедура это декоратор функции, или нет, всё плохо

(202) В Обероне откуда вышел Паскаль процедур и функций нет вообще!
Там только модули.

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

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

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

(205) Это я так, кратко изложил концепцию :)

(204)+ Хотя ошибся, там есть процедуры но нет функций ))

Интересно если зайти на форум C++ и предложить отказаться от void в пользу какого нибудь класса с результатом работы функции, сс*ми тряпками сразу закидают или подождут?

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

(208) В С++ "void" можно рассматривать как указание для функции 0 возвращаемых значений.

(192) > Правило - "Доверяй, но проверяй"
Для этого есть модульные тесты

(210) Что и есть процедура.

Так будет пример для ЯП 1С где нельзя обойтись без Процедур?

(212) Человек не выполняющий полезной работы перестает быть человеком?
А не возвращающий полученные деньги?

(211) Да ты ШО :)))

Год работы по системе BDD от "Сильвер Спун" меня многому научили, поверь! И это никак не повлияло на "Доверяй, но проверяй"

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

И да почему Функция возвращает только одно значение в большинстве старых ЯП?

Вот в новых (например Golang) Функция может возвращать несколько значений!
Это реально удобно не надо обертки с составными типами придумывать для возврата нескольких.

(216) Процедур нет, это подвид Функций. Прцедура это урезанная Функция.

(218) Чем же урезанная? Давайте разберемся до конца!

(219) Отняли возможность возвращать даже одно значение ))

(220)+ Только через передачу параметров по ссылке можно из Процедуры что то вернуть.

(221)+ Ну или через изменение глобальных переменных

(208) ходят слухи, в этих ихних C++ можно чуть ли не любое ключевое слово заменить с помощью #define и каких-то там трюков, тем самым как бы локально переделав C++ в собственный ЯП

(220) Отлично! Процедура это функция, которая не возвращает значение. Т.е. void P(t) это процедура.

Кстати само название "функция" как подрограммы пошло именно из математики, из выражений типа y=F(x);

Объединение функция и процедур произошло в языках позже для удобства синтаксиса.

(213) обработчики, не?

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

(225) Хороший пример, но это принудительное ограничение от разрабов платформы 1С.

(215) "Год работы по системе BDD от "Сильвер Спун" меня многому научили, поверь"
это не аргумент

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

(228) Для кого как

Когда мне довелось массово переводить одну конфу с ОФ на УФ с работой под веб-клиент (безмодальность, асинхронные вызовы и все дела), я долго проклинал любителей злоупотребить функциями где ни попадя. Из-за их болезненной манеры всё подряд делать функциями, многие куски кода приходилось переписывать заново. В то время как нормальный код переделывался автоматически, или с небольшими переделками ручками

(227) Допустим платформенного ограничения нет и обработчики событий и оповещений могут возвращать значения. Какие Вы бы вернули значения и кому?

Ну дык процедура на 28% длиннее функции. Соответственно кто вместо процедуры пишет функция, работает на 28% эффективнее перфекционистов.

(233)
проCtrl-пробел
фунCtrl-пробел

ровно одинаковое количество

(234) А количество текста? Размер диска тоже не бесконечен :)

(234) вы все еще набираете текст на клавиатуре? голосовой набор уже лет 15 как рулит.

(236) а как голосовой набор справляется с CamelCase и символами в коде?

(237) Голос повышаешь и все

(141) я засчитываю слив

(231) Вот про асинхронность не надо. Она просто сделана так, что без мата невозможно)))

(240) Она просто сделана. Точка.
Но когда цепочка асинхронных вызовов превышает "адын", то глаза вытекают :)
Я в таких случаях использую хитрый прием, когда за все отвечает один обработчик, в котором логика обработки разбита на этапы и расположена последовательно.

(240) не, ну когда код написан нормально, и всё на своих местах, то та асинхронность вообще не проблема. Рефакторинг - Нерекомендуемые синхронные вызовы - Преобразовать вызовы модуля. Может полностью переделать всё автоматом. Но если кто-то порукожопил в форме, то переделывание на асинхронные вызовы становится теми ещё шарадами

(242) Я асинхронные вызовы так и пишу до сих пор :) Пишу сначала синхронный (там уже все наизусть со старых времен), а потом мастером переделываю.