Функция ПолучитьПутьКФайлу(Токен, file_id) Экспорт
    
    ПутьКФайлу = Неопределено;
    Результат = Истина;
    
    Соединение = СоединениеТелеграмм();
    
    Ресурс = "bot" + Токен
        + "/getFile"
        + "?file_id=" + file_id;
        
    Запрос = Новый HTTPЗапрос(Ресурс);
    
    Попытка
        
        Ответ = Соединение.Получить(Запрос);
        
    Исключение
        
        ТекстСообщения = "Ошибка получения данных файла " + file_id + " "  + ОписаниеОшибки();
        СообщитьОбОшибке(ТекстСообщения);
        Результат = Ложь;
        
    КонецПопытки;
    
    Если Результат Тогда
        
        КодСостоянияУспешно = 200;
        Если НЕ Ответ.КодСостояния = КодСостоянияУспешно Тогда
            
            ТекстСообщения = "Сервер вернул ошибку " + Ответ.КодСостояния;
            СообщитьОбОшибке(ТекстСообщения);
            Результат = Ложь;
            
        КонецЕсли;
        
    КонецЕсли;
    
    Если Результат Тогда
        
        СтрокаОтвет = Ответ.ПолучитьТелоКакСтроку();
        ДанныеОтвет = ReadFromJSON(СтрокаОтвет);
        
        Если ДанныеОтвет.ok = Ложь Тогда
            ТекстСообщения = "Ошибка в отправленных данных";
            СообщитьОбОшибке(ТекстСообщения);
        Иначе
            ПутьКФайлу = ДанныеОтвет.result.file_path;
        КонецЕсли;
        
    КонецЕсли;
        
    Возврат ПутьКФайлу;
        
КонецФункции

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

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

(50) Для меня - не проще. я вижу "Тогда", но не вижу что там где Иначе и есть ли оно вообще...
Труднее код анализировать.

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

(73) Я просто стараюсь писать без Иначе (очень часто от него можно избавиться) и избегаю портянок.

(53) согласен.
но я так не люблю
.
Если ОтТрехСотТыщ(Сумма) Тогда
        ВесьЦеликомВаш();
ИначеЕсли..
- а вот там.. в самом конец где конецЕсли - там что-то еще есть? ХЗ....
а если возврат влепить сразу - то логика уже заонченная я ВесьЦеликомВаш() и всё.
.
но я никак не определюсь - то ли к умным то ли к красивым..
то так.. то так...

(71) >>это усложнение без профита

Нет, дорогой друг, это упрощение и инкапсуляция. Что проще, прочитать название метода или 15-20 строк кода? По-моему ответ очевиден

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

Функция ПутькФайлуИзТелеграмм(Токен, ИдФайла)
    
    АдресФайла = АдресПолученияФайла(Токен, ИдФайла);
    
    ПутьКФайлу = Неопределено;
    Попытка
        Соединение = СоединениеТелеграмм();
        СтрокаJSON = ФайлИзИнтернета(Соединение, АдресФайла);
        ПутьКФайлу = ПутьКФайлуИзОтветаИнтернетСервиса(СтрокаJSON);
    Исключение
        ТекстСообщения = СтрШаблон("Ошибка получения данных файла %1 : %2", ИдФайла,  ОписаниеОшибки());
        СообщитьОбОшибке(ТекстСообщения);
    КонецПопытки;
    
    Возврат ПутьКФайлу;
    
КонецФункции

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

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

(77) Э нет, дорогой друг. Я давно лаптями щи хлебаю и все эти варианты я проходил. Удобнее и проще поддерживать простую и понятную функцию на 15 строчек кода. И декомпозировать ее только тогда, когда это действительно понадобится. С предварительными идеальными абстрагированиями до трехстрочных функций - удобнее сопровождать? Сыросли? Я знаю эти тенденции и баба яга против. Да, ты в итоге поправишь минимум кода, потому что у тебя уже все идеально декомпозировано ранее. Но до того, как реальная необходимость в декомпозиции возникнет - ты постоянно будешь тратить время и силы на восстановление контекста.

(79) ты о чём вообще? Я где-то призывал писать каждую строку кода в отдельной функции?

"Но до того, как реальная необходимость в декомпозиции возникнет" - если она ВООБЩЕ возникнет

(80) >>ты постоянно будешь тратить время и силы на восстановление контекста

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

(82) декомпозицию в коде нужно делать сразу. А не когда рак на горе свистнет, и автор кода три года как уволился

(83) Вот не надо утрировать. Я говорю предельно конкретно. Пока не возникнет реальная необходимость в декомпозиции, лично мне удобнее сопровождать (29), чем (65)
Так ферштейн? И я готов побиться об заклад, что я далеко не один такой.

(85) чем удобнее? Я же объяснил, (0) и (29) вынуждают "впервые заглянувшего" прочитать больше строк кода, чем (65)

Вспоминаю свои "счастливые" времена работы с ЗУП 2.5. Это был полный кабздец. Такое ощущение, что разработчики того ЗУПа считали дурным тоном писать методы короче 500 строк. Чтобы найти ту сраную "Если...Иначе", в которую тебе надо воткнуть свои две строки кода, приходилось проутюжить глазами тысячи строк кода...

(0) имя функции должно отражать ее суть, а у тебя - хз что происходит

(0) СообщитьОбОшибке(ТекстСообщения);
- кому и что ты собрался сообщать?

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

(49) Спасибо.

(65) Хм. Интересно.

(88) Ну, а какое например?
// Функция получает путь к файлу. В дальнейшем используя путь можно получить файл.

(89) Себе, ну и коллегам в канал телеграмм.

Отдельное спасибо Конструктор1С

(0)Коль пошла така пьянка... :)

//стрПараметра = Новый Структура() - С кучей параметров, ограниченных фантазией Программиста :)
Функция ПолучитьПутьКФайлу(стрПараметра) Экспорт
    
    Токен =  стрПараметра.Токен;
    file_id =  стрПараметра.file_id ;

    Если стрПараметра.Свойство("Соединение") Тогда
       Соединение =  стрПараметра.Соединение;
    Иначе
        Соединение  = Неопределено;
    КонецЕсли;

    ПутьКФайлу = Неопределено;
    Результат = Истина;
    
    Если Соединение  = Неопределено Тогда
       Соединение = СоединениеТелеграмм();
    КонецЕсли;
    
    Ресурс = "bot" + Токен
        + "/getFile"
        + "?file_id=" + file_id;
        
    Запрос = Новый HTTPЗапрос(Ресурс);
    
    Попытка
        
        Ответ = Соединение.Получить(Запрос);
        
    Исключение
        
        ТекстСообщения = "Ошибка получения данных файла " + file_id + " "  + ОписаниеОшибки();
        СообщитьОбОшибке(ТекстСообщения);
        Результат = Ложь;
        
    КонецПопытки;
    
    Если Результат Тогда
        
        КодСостоянияУспешно = 200;
        Если НЕ Ответ.КодСостояния = КодСостоянияУспешно Тогда
            
            ТекстСообщения = "Сервер вернул ошибку " + Ответ.КодСостояния;
            СообщитьОбОшибке(ТекстСообщения);
            Результат = Ложь;
            
        КонецЕсли;
        
    КонецЕсли;
    
    Если Результат Тогда
        
        СтрокаОтвет = Ответ.ПолучитьТелоКакСтроку();
        ДанныеОтвет = ReadFromJSON(СтрокаОтвет);
        
        Если ДанныеОтвет.ok = Ложь Тогда
            ТекстСообщения = "Ошибка в отправленных данных";
            СообщитьОбОшибке(ТекстСообщения);
        Иначе
            ПутьКФайлу = ДанныеОтвет.result.file_path;
        КонецЕсли;
        
    КонецЕсли;
        
    Возврат ПутьКФайлу;
        
КонецФункции

(93) Спасибо. А чем "Структура" лучше, пары параметров?

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

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

Пример:

Функция СтаннаяИНепонятная(Параметр1, Параметр2, Параметр3, Параметр4, Параметр5, Отмена, ЧтоТоЕщеЗабылиНоХочется=Неопределено, АВотЕщеЗабыли=Ложь)

(95) Не, это не наш подход. Универсальные функции с огроменным функционалом это не то о чем стоит мечтать.

До 3х параметров лучше отдельно

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

(98) Да не, ТС(0) попросту тогда придется переписать сам принцип работы с кодом.
Теряется смысл и замысел от Функций :)

Получится так, что процедуры уже будут более насыщенными...

(90) А в области закрыть чем хуже?

(98) > божественного метода
Напомнило.

"Интерфейс с единственной кнопкой "сделать все" реализован только в ядерном чемоданчике Президента и предназначен для однократного применения."

(:

НЕ Ответ.КодСостояния = КодСостоянияУспешно

за такое надо бить.

(98) В 1С это божественный запрос.

(102) Чего так?

(102) Коллега, хоть как-то аргументируйте свои высказывания.

А НЕ быть не должно если можно сделать так Ответ.КодСостояния <> КодСостоянияУспешно

(106) Продолжайте. Не должно быть по причине?..

Использование конкатенаций  - это все устарело.
Ресурс = "bot" + Токен
        + "/getFile"
        + "?file_id=" + file_id;

Ресурс = СтрШаблон("bot%1/getFile?file_id=%2", Токен, file_id)

(107) Усложенние кода. Он  использовал да оператора на ровном месте, там где нужен был один и ухудшил читабельность.

(109) Насчет читабельности спорно. Для меня НЕ = глазами распознается быстрее.

(110) +1
(102) Меня больше раздражает само размножение сущностей. Зачем нужна КодСостоянияУспешно, если она тут же строчкой выше присваивается и больше нигде никогда не используется? Или у нас в обозримом будущем планируется менять коды состояний HTTP?...

(109) Спорно же
"<>" => "<" "ИЛИ" ">"
"НЕ = " => "НЕ" "="
:)

(111) Это для коллег, которые HTTP запросами не работали.

(100) да ничем, собственно. дело привычки. делал так еще до того, как появились области)

(111) У меня для таких случаев гроздь функций типа

Функция КодСостоянияУспешно() Экспорт Возврат 200; КонецФункции
Функция КодСостоянияПлохойЗапрос() Экспорт Возврат 401; КонецФункции
Функция КодСостоянияНеНайдено() Экспорт Возврат 404; КонецФункции
Функция КодСостоянияОшибкаСервера() Экспорт Возврат 500; КонецФункции

как-то так

(115) я даже готов это принять, но, господи, почему не сделать хотя б фиксированную структуру или что-то типа того? Зачем весь этот изврат? :(

(116) Затем, что программноопределяемых перечислений в 1С нет. Фиксированную структуру без танцев с бубном глобально видимой не сделать.
Можно, конечно, влепить перечисление. Но тоже такой себе вариант.

Поэтому, из вариантов написать:

Перечиления.КодыСостоянийHTTP.Успешно

ОбщийHTTP.КодыСостояний().Успешно

ОбщийHTTP.КодСостоянияУспешно()

я выбрал последний

(11) имя переменной поясняет данное числовое значение. Вообще это хороший тон в программировании - выносить константные значения в "самодокументирующиеся" переменные. Вот увидел ты в коде дату 21.12.2012, о чём она тебе говорит? Да ниочём. А если вот так?

КонецСвета = Дата(2012, 12, 21);

(118) к (111)

(118) Если вынести за скобку, что речь идёт о стандартных кодах возврата HTTP, которые не меняются в принципе (и интерпретация которых у разных API может быть разная, к слову),

я не вижу принципиально разницы между

Если МояДата = Дата(2012, 12, 21) Тогда //дата конца света
    НамВсемПЦ();
КонецЕсли;

И

КонецСвета = Дата(2012, 12, 21);
Если МояДата = КонецСвета  Тогда
    НамВсемПЦ();
КонецЕсли;

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

(115) код состояния 200 и так все знают, а остальные и смысла нет перебирать

(121) ну, я иногда редиректы и отсутствие оплаты обрабатываю. Но по разным API разные цифры для этого используют.

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

Если Документ.Дата >= Дата(2019, 6, 30) Тогда
    Документ.Организация = Справочники.Организации.НайтиПоНаименованию("ООО Ветерок");
Иначе
    Документ.Организация = Справочники.Организации.НайтиПоНаименованию("ИП Пупкин");
КонецЕсли;

В данном случае что означает 30 июня 2019 года? И почему эта дата влияет на выбор организации?

(123) можно же коммент написать. в чем разница с именованной переменной?

(124) Как минимум в том, что не нужно искать этот коммент, встретив переменную.

(125) искать???

(120) У тебя слишком вымороченный пример, ты вытащил весь контекст в одно место.
Вот, сравни:

ОбработатьОсобуюДату(ТекущийДокумент, Дата(2019, 6, 30));
ОбработатьОсобуюДату(ТекущийДокумент, Дата(2012, 12, 21));

И

ДеньРожденияБосса = Дата(2019, 6, 30);
ОбработатьДатуСкидки(ТекущийДокумент, ДеньРожденияБосса);

ДеньКонцаСвета = Дата(2012, 12, 21);
ОбработатьДатуСкидки(ТекущийДокумент, ДеньКонцаСвета);

(123) > контекст уже обнажён, он у тебя в голове и тебе понятен
Вот точно.

(123) (127) Вы в (120) не увидели, что я для этой цели использую аккуратный комментарий. Когда делаешь какую-то дичь в коде (а хрень типа прописать в коде дату ДР босса = дичь), то самое оптимальное как раз прописать комментом:

ОбработатьОсобуюДату(ТекущийДокумент, Дата(2019, 6, 30));   //ДР босса
ОбработатьОсобуюДату(ТекущийДокумент, Дата(2012, 12, 21));   //Конец Света

Плюс изначальная моя претензия - эти вновь объявленные переменные нигде дальше не используются и никогда не будут. Если условная ДеньРожденияБосса используется в 20 местах по коду, я это готов принять и понять (и то ВСЕГДА лучше константой забубенить), а вот так объявить и тут же использовать - не понятно зачем.

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

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

(86) Мой поинт вот в чем: чаще всего код приходится анализировать в процессе траблшутинга. А ошибка сплошь и рядом таится не прямо в месте где она выстреливает. Ты попадаешь в окрестности кода и пытаешься впитать максимум контекста. В итоге чаще всего придется заходить и анализировать все связанные функции, потому что ты в этот момент не можешь быть уверен в их беспроблемности. Если же мне нужно доработать код в условиях декомпозиции до трехстрочных функций - мне придется сильно поднапрячься, если текущая декомпозиция неидеальна под новые требования (а это еще необходимо осознать). И тут кроме доп-когнитивной нагрузки мне нужно проанализировать также все использования доп-функций (а не дай бог какие-то еще и экспортные "про запас").
С опытом я стал делать иначе. Если функция все еще хорошо читается и укладывается в пол-экрана или даже экран (но не больше) - то я не тороплюсь ее декомпозировать, если не предполагаю пользу от этого в ближайшем будущем. Зачем? Необходимость в переиспользовании кода еще не возникла. Я уверен в том, что смогу сразу и без оглядок по сторонам ее рефакторить, когда такая необходимость возникнет (и я стараюсь писать именно с прицелом на легкость рефакторинга в будущем). Все и так отлично.
В подобных "подстеланиях будущей соломки" безусловно ведущую роль играет опыт. Если понимаешь что с высокой степенью вероятности какой-то код может быть переиспользован в ближайшем будущем или читабельность функции начинает хромать или она начинает превращаться в портянку - тогда декомпозируешь сразу. Опять таки - в пределах разумного.
Но декомпозировать исключительно чтобы избавиться от банальных проверок на допустимость входящих параметров и промежуточных результатов с досрочным выходом из функции? Увольте. Это не мой путь. Это уже какое-то "горе оверинжениринга от ума".
Мой девиз - "максимальная читабельность и легкость доработок". Реальная легкость доработок, а не гипотетическая. Потому что декомпозиция до трехстрочных функций "из принципа" - дает лишь гипотетическую легкость доработок и нередко наоборот - затрудняет их.

(131) "А ошибка сплошь и рядом таится не прямо в месте где она выстреливает. Ты попадаешь в окрестности кода и пытаешься впитать максимум контекста. В итоге чаще всего придется заходить и анализировать все связанные функции, потому что ты в этот момент не можешь быть уверен в их беспроблемности. " зачем заходить и анализировать все связанные функции? Достаточно посмотреть где неправильный параметр и зайти в ту процедуру. Вот у меня недавно было с перепиленной конфой. Документ не проводится а ошибок никаких не выдает. а потому что кто то втулил проверку в конце обработки проведения
Если КакоетоУсловие() Тогда
Отказ = Истина;
КонецЕсли;
И тут два варианта первый:
Процедура ОбработкаПроведения(Отказ)
ПроверкаШапки(Отказ);
ПроверкаТЧ(Отказ);
ПроверкаВторойТЧ(ОТказ);
ЕщеКакоеТонепонятнаяПроверка(Отказ);
КонецПроцедуры
и я просто отладчиком прохожу нахожу процедуру в после которой отказ стал истина и захожу в нее,
Второй вариант я листаю процедуру длиной 1430 строчек кода и пытаюсь найти где отказ стал истина

(132) эх, а вот если бы была возможность остановки по изменению переменной ...

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

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

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

(131) >> ошибка сплошь и рядом таится не прямо в месте где она выстреливает

Это тоже из-за нарушенной декомпозиции

(134) > отладка возможна не всегда
Точно, в какой-то из версии платформ проклятые парни с Дмитровского шоссе наглухо выпилили методы Сообщить и ЗаписатьВЖурналРегистрации. Общеизвестный случай!

Я поделился своим мнением, сложившимся в процессе долгой практики и как мог попытался его обосновать, в надежде что оно кому-то покажется интересным. Суть его можно выразить фразой - "не тратьте силы на упрощение того, простота чего уже является достаточной". Только хуже будет. Если код уже хорошо читается, хорошо управляется и его легко будет отрефакторить - остановитесь. ЭТО оптимальное состояние кодовой базы. Именно ЭТО, а не обязательная декомпозиция до трехстрочных функций исходя из "идеального видения" на текущий момент.
Если я не встретил понимания - что ж. Меня уже не переубедить. Засуну свое мнение подальше.

(133) Чем точка остановки с условием не подходит ?

(132) а я просто ставлю точку остановки с условием. И не бегаю как угорелый.

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

(141) так нужно понять куда ее ставить, ведь в тексте ее могут поменять в десятке мест

(142),(143)

        <bpInfo>
            <line>1</line>
            <condition>Отказ = Истина</condition>
        </bpInfo>
        <bpInfo>
            <line>2</line>
            <condition>Отказ = Истина</condition>
        </bpInfo>
...............................................................
        <bpInfo>
            <line>1374</line>
            <condition>Отказ = Истина</condition>
        </bpInfo>


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

(145) самое сложное в этом, что новый прог не знает 95% методов и делает свои аналогичные

(144) эм. я человек темный необразованный. это что?

(146) а это уже другая печальная история( Когда даже методов типовой не знает новый прог и пишет свои абсолютно аналогичные.

(139)  +1

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

(146) было бы очень легче, если бы в СП можно было редактировать в конфигураторе и добавлять свои разделы по общим модулям

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

(144) гуд!
(147) файл с точками останова, загружается через Отладка - Список точек останова

(152) ага, его можно слепить для каждой строки программно)
извращение, конечно.. но всё же

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

(129) >>самое оптимальное как раз прописать комментом

ничего оптимального

>>эти вновь объявленные переменные нигде дальше не используются и никогда не будут

готов зуб дать, что никогда не будут использоваться? Придёт другой прогер, полезет дорабатывать код, захочет повторно использовать это значение и что он сделает? Правильно, скопипастит константу...

(139) "не тратьте силы на упрощение того, простота чего уже является достаточной"

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

P.S. то что ты называешь "тратить усилия", таковым и не является. Это всего-лишь стиль разработки. Либо сразу осознанно писать код с декомпозицией, либо городить функции-портянки, делающие всё и сразу

P.P.S. свой код всегда кажется простым и понятным, не надо прибывать в иллюзии простоты здоровенной функции. Простой она является только для автора

(142) >>есть надцать процедур, в каждой из которых переменная может быть изменена?

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

(154) > имя переменной надёжнее
Кстати да, константа семантически оформляется практически так же, как и переменная - через имя. Поэтому остаются только вопли об однократном использовании =)

(156) >  свой код всегда кажется простым и понятным
Это только первую неделю.

А в 1С уже завезли юнит тесты?

Тесты конечно же есть, моков нет

(159) ещё только-то пытаются

(160) это скорее вопрос к подходу написания кода

(157) главное, чтобы гипервентиляция не случилась, пока ты дышишь над текстом ЕРП

(160) они уже встроенны или нужно Ванессу ставить?

(160) Это которые плагин Саши Капралова к EDT?

(163) только встроенные решения признаешь?

(165) признаю только хорошо интегрированные в экосистему языка решения для юнит тестирования.

(166) > в экосистему языка
Этачотакое для 1С?

(167) То есть за 23 года существования 1С так и не удалось построить для нее экосистему?

Появившийся в 95м году Java смог это сделать. Причем так, что все копируют с нее эту экосистему.

(168) Я тебя про определение спрашивал. А тебя куда-то уже в разглагольствования понесло.
Что такое, по твоему, экосистема для 1С?

(166) это скорее больше вопрос к среде разработки. Может у кого-то рукастого руки дойдут написать грамотные плагины для поддержки юнит-тестирования. Вендор на юнит-тесты болт положил