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

М.Фаулер, "Рефакторинг. Улучшение проекта существующего кода"
https://www.ozon.ru/context/detail/id/141508653/

С.Макконел, "Совершенный код"
https://www.ozon.ru/context/detail/id/138437220/

Р.Мартин, "Чистый код: создание, анализ и рефакторинг"
https://www.ozon.ru/context/detail/id/28336354/

А вы как считаете?

(251) А как же излишняя беготня по vTable или я несколько позабыл уже внутренности?

(252) Ну да, слегка приврал. Три обращения к памяти требуется.

(252) Прекращайте про виртуальные функции. Давайте про 1с.

(254) Хорошо, что в 1С есть ООП, наследование и полиморфизм с виртуальными методами.

(254) Ты же начал? Расскажи нам, где там чо?

(256) Книжку почитай

(255) Хорошо

(257) Нет у меня книжек. В n-словах можешь рассказать, в каком месте в 1С виртуальные методы? И почему это тормоза?
Про кривые ручки мне понятно, можно не объяснять.

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

(259) Я не говорил, что в 1с есть виртуальные методы. Хотя внутри есть конечно же. Раз 1с тормозит - значит точно есть :)

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

С этим никакие виртуальные методы и рядом не валялись.

(262) и какая причина торможения "врег(сокрлп(св.свойство))"?

(263) Если эту фигню 20 раз выполнить в рамках одного метода, то какая-то, хотя и не шибко большая. Уж точно больше, чем виртуальные вызовы.
Или к примеру сериализация всего и вся при передаче с клиента на сервер и обратно. Тоже скорости не добавляет. Опять же, на порядки больше виртуальных вызовов.

(264) чо ты паришься. в 1с нет виртуальных методов.

(265) Патамушта В ИНТЕРНЕТЕ КТО-ТО НЕ ПРАВ!!!!

(249) Это значит, что вот так вот напренебрегали.

В 1с есть виртуальные методы

новый описание оповещения - создание,
а там,где надо вызывается выполнение.

точнее,это указатели на функцию

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

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

Экономить на вызовах методов имеет смысл только когда все остальные оптимизации уже сделаны - алгоритмические в первую очередь. А то нафигачат запросов в циклах, и жалуются - у 1С вызовы методов долгие, поэтому все и тормозит)

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

(246) не будет. Всё изначально будет на своих местах. Если, конечно, автор процедур не наговнокодит с параметрами процедур

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

(252) вот вам короткие функции 1С

Функция ПолучитьСтавкуНДС0() Экспорт

Функция ПолучитьСтавкуНДС10() Экспорт

Функция ПолучитьСтавкуНДС18() Экспорт

Функция ПолучитьСтавкуНДС20() Экспорт

Функция ПолучитьСтавкуБезНДС() Экспорт

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

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

(273) "Если есть проект и алгоритм - разбить можно будет и потом без особых проблем"

Не можно. Если используются большие процедуры, это УЖЕ говорит о плохом проектировании. Или может покажешь большую процедуру/функцию, в которой всё гладко? Разделять на небольшие процедуры нужно сразу, чётко следуя принципу: одна процедура/функция для одной цели

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

(276) может, но в гораздо меньшей степени. Например, в небольшой процедуре не получится инициализировать переменную на 200 строк раньше её использования, если в этой процедуре всего 20 строк.

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

(277) :) Ага, она будет инициализирована на 10 функций раньше и передана в структуре.

(0) https://i.ibb.co/Hp8nfqw/1435664542-kem-byl-nyneshniy-geroy-populyarnyh-memov-morihey-uesiba-1.jpg

(278) Помимо "хорошо" есть ещё "легко читабельно". Когда я ЗУПовую портянку вижу, тоска приходит.

(281) Представь, что они разобьют ее на сотню процедур в разных модулях. Легче станет?

(282) Гораздо.

(283) :) Лучше будет скакать туда-сюда, да еще и с менеджером временных таблиц в качестве параметра? Вам недостаточно запросов, собираемых в куче модулей?

(284) Ну какбе совсем необязательно из крайности в крайность кидаться.

(268) Эта тема будет работать только на клиенте

(285) Мне кажется, проблема в том, что понятие "читабельность" не очень то формализуется. А людЯм подавай чёткие определения. Вот размер метода - штука крайне понятная - поэтому все к ней привязались, как будто это что-то самоценное. На самом же деле размер и читабельность конечно коррелируют, но функционально даже не связаны.

Чтение данной темы неизменно вызывает в памяти фразу:
- Старайся делать хорошо. Плохо само получится.

Зачем стараться сделать плохо, да ещё и гордо показывать: смотри, какое г. получилось?!

(236) (244) то есть, компиляция 14000 строк менее затратное по времени дело, чем вызов десяти процедур каждая в 30 строчек?

(288) Вопрос в стиле "Кто круче: лыжник или сноубордист?"

(289) ну почему же? Лыжник или сноубордист это вопрос вкуса, а тут имеем два измеримых варианта - 14 000 строчек кода. Плюсы - вызов одной процедуры вместо десяти - экономия на вызовах, минуса - компилируется лишний код; большие затраты на внесение изменений и отладку отчета.
Второй вариант, 10 процедур общим объемом в 300 строк кода. Минус - каждый раз при формировании отчета делается вызов 10 процедур, Плюс - читаемость кода, меньше времени нужно на исследование, отладку и внесение изменений в отчет раз в 20.

(285) Просто я представляю себе, как разделят создатели ЗУПа свою портянку.

(288) Компиляция делается 1 раз, а программа исполняется миллионы раз.

(291) в 1с разве встроенный код не компилируется каждый раз  при открытии формы?

(292) Так делает интерпретатор, а не компилятор. Компилятор делает свою работу 1 раз, и на выходе получает исполняемый на выбранной машине код, а потому затраты на компиляцию будут нулевые.

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

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

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

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

(293) но все равно затраты времени на выполнение интерпретатором идет каждый раз при открытии формы. (295) это как проще анализировать? у вас идет
Если Условие1 Тогда
50 строчек кода;
Если условие2 тогда 50 строчек кода
Иначе
48 строк кода;
если условие3 тогда
45 строк кода
иначеесли 65 строк кода.
и ты тут такой сидишь и вспоминаешь комбинацию всех трех условий

(290) Крутость - так себе зависит от "лыжник или сноубордист", но что за зависимость вы спросили в "компиляция 14000 строк менее затратное по времени дело, чем вызов десяти процедур каждая в 30 строчек?" - это настолько разные "время", что их не то что сравнивать, в одном абзаце-то нельзя упоминать.
До кучи, 30*10 = никак не 14000.

(296) 1. Затраты идут на весь модуль, а не на используемый в данный момент код. Так что в первом приближении нет разницы, разбито или нет. А уж если разбито в 100500 модулей, как это любят делать создатели типовых - так еще и медленнее получится.
2. Во-первых, сворачивание условий настраивается. Во-вторых, чтобы в общем понять работу программы - надо смотреть алгоритм, а не код. А уже потом если что-то где-то не работает, или работает не по алгоритму - вот тут и искать. И заходить придется везде в таком случае. И тем же отладчиком смотреть удобнее когда оно все вместе.

(297) там меня поправили, исполнение интерпретатор, а не компиляция занимает время. Поправьте, если я не прав, но при открытии интерпретатор должен обработать весь модуль в 14 000 строчек и исполнить. "До кучи, 30*10 = никак не 14000." естественно потому что идет дублирование кода в 14 000 строчках, где в разных ветках выполняется одинаковый код для разных таблиц значений с одинаковой структурой.

(298) 2. Во-первых, сворачивание условий настраивается. - как это поможет когда вы в 7 уровне вложенности и вам нужно  посмотреть на каком уровне вложенности инициализировалась данная переменная?
Во-вторых, чтобы в общем понять работу программы - надо смотреть алгоритм, а не код - как можно посмотреть алгоритм формирования отчета в одной процедуре в 14 000 строк не глядя на код?

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

(299) Предлагаете 1500 употреблений "КонецЦикла" в 14000 строчек кода как-то заменить десятью процедурами по 30 строчек кода? Это как это? Или какой у вас код должен дублироваться целыми строками на протяжении 14000 строк? Пустые строки - разделители?

(300) 1. Поиск назад нормально работает. В отличие от разбитых по процедурам кусочков кода.
2. Алгоритм смотрится в документации к программе.

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

(295) "Анализировать визуально как раз проще - слишком глубокая вложенность циклов и условий видна сразу"

и какова радость от этой видимости? Сиди себе, собирай пазл, пытайся понять, как оно там устроено и работает. Есть такое понятие - декомпозиция задачи. Это раскладывание одной большой и сложной задачи на множество маленьких и простых. В программировании декомпозиция рулит как нигде. Если декомпозиция задачи плохо проведена, алгоритм не продуман, начинаются появляться такие вот огороды:
https://www.govnokod.ru/22113
а то и гораздо хуже

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

За все свои года одинэсинья ни разу не видел такой документации. Где можно посмотреть? Обычно в документации написано так: "себестоимость материальных запасов будет списана при проведении документа ХХХ", а за этой скупой фразой стоят 10 тысяч строк кода.

(303) Серьёзно?
Вот только что, ЗУП 3.1.5.Последний
СЗВ_КОРР - дублируются строки о стаже.
Страницу документации, пожалуйста

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

(304) Вот и надо начинать с получения этой документации, а не разбиения. Без этой документации нормального разбиения все равно не будет. Это как телегу впереди лошади ставить и обсуждать - как ее лучше запрячь.

(305) Вы, как разработчик ЗУП, должны иметь к ней доступ.

(307) Серьёзно? Понятно всё с вами. Вам просто всем сказать, какие они не умные, один вы всё знаете как правильно.

(306) вообще-то у отладки задача совершенно другая - поиск и устранение ошибок, а вовсе не разбор сложнозапутанного кода.

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

(299) зачем интерпретатору разбирать строку до которой он не доходит?
я считал что будет выполняться (и интерпретироваться предварительно) только та ветка (5% кода) в которую мы попали по многочисленным проверкам условий.
или 1с интерпретирует все полностью?

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

(302) ну там был код:
Перем Тз1 Тз2 Тз3 ... тз10
Если условие1 Тогда
еслиусловие1.1 тогда
тз1.Добавить();
тз1.пол1 = значение1
---
тз1.Поле14
еслиусловие1.2 Тогда
тз2.Добавить();
тз2.пол1 = значение1
---
тз2.Поле14

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

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

(310) самому интересно. просто вот явная ошибка синтаксиса в общем модуле ругается при обращению к общему модулю, а конструкции типа Объект.ЧТотоСделай() где у объекта нет такой функции ошибки не выдает, пока не зайдешь в нужную ветку.

(312) Наверное, всё-таки, на "10", без "к"? Просто даже модуль обработки для регламентированной отчётности - 18к...
И там нормальные такие коды зашифровки/расшифровки...

(315) это был семерошный отчет переданный мне по наследству  от другого франча. и судя по количеству галочек на форме и их наименованию этот отчет переписывался периодически лет 7. Тогда я впервые в жизни узнал слово рефакторинг кода и понял зачем он нужен, когда добавление одной расчетной колонки (показатель11-Показатель10 ) в отчете заняло 8 часов доработки и отладки

(308) Если вы не пишете ЗУП - то и повлиять на разбиение не сможете. О чем тогда разговор?

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

(310) Как минимум синтаксический контроль проходит весь модуль.

(317) Какой документации, поясните? Отдельный талмуд, описывающий каждую функцию модуля?

(318) и отдельно талмуд к каждому обновлению

(318) Документация включает, как минимум:
1. Проект с ФМ и структурой данных.
2. Алгоритмы, реализованных в коде, с привязкой к ФМ.

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

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

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

(320) Вы на ЗУП что-то подобное видели?

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

(320) вот вышла редакция ерп 2.2 к ней нет документации. вы  хотите ее поддерживать и внедрять. Вы сами будете к ней документацию писать?

(323) Ога, "надо начинать с документации" же :)

(323) Получается, что да. Ведь правильно сначала написать документацию, если её нет... А - нет! Затребовать от 1С надо документацию и, в случае непредоставления - отказаться от использования и, тем более - поддержки.

Видите, как мы все неправильно работаем! А потом на 1С жалуемся, хотя сами - палец о палец не ударили, чтобы всё было хорошо и с документацией.

(321) В 1С должен быть, иначе текущие типовые просто посыпались бы уже.

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

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

(323) Прежде чем делать доработки, необходимо составить такую документацию, если у вас ее нет. Но 1С крайне не рекомендует вообще лезть в код ERP, так что какая разница какой длины функция?

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

Не, ничего против документирования я не имею, более того, требую от своих сотрудников комментировать код и писать краткую документацию к доработкам, касающимся пользовательского интерфейса, но устраивать балаган с тотальным документированием КОДА...

(328) Не кода, а алгоритмов. Код - это выходной результат, его документировать не надо.

(327) >В 1С должен быть, иначе текущие типовые просто посыпались бы уже

Вы хоть раз видели такую документацию, предоставляемую сторонним разработчикам?

(329) >Не кода, а алгоритмов

Код - это и есть алгоритм, изложенный в ЯП. Вы предлагаете его помимо ЯП, ещё и человеческим языком подробно расписывать?

(329) Похоже, вы невероятно путаете "рекомендации к разработке" с документацией. Алгоритм и его программную реализацию (детализацию). И не факт, что реализация, выполняя алгоритм на 100%, не имеет мест, которые расширяют этот алгоритм в баги.

(330) 1. Такую документацию сторонним разработчикам не предоставляют по понятной причине. Ибо именно она имеет самую высокую ценность.
2. _СНАЧАЛА_ расписываете человеческим языком, что и каким образом вы хотите получить (по пунктам), _ПОТОМ_ пишете код (по пунктам).

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

А в документации-то всё в порядке будет: "при выборе Сотрудника - заполнить ТЗ стаж". А вот в реализации:
"ПриОкончанииРедактированияСтроки", а строка - один только Сотрудник. Всё верно? Ошибка, судя по документации есть? А судя по реализации?

(333) Вам надо детализировать что значит "заполнить ТЗ стаж". Так, чтобы каждый пункт реализовался кодом на 1 экране.

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

(334) Не имеет смысла. Ошибки там нет - оно работает корректно. Ошибка в дублировании данных в ТЗ Стаж в итоге выполнения этой части Алгоритма. Но где же?

(335) Это не двойная работа, это подготовительный этап к тому, о чем пишется в (0). Надо просто взять и формализовать оформление такой декомпозиции, чтобы прикладывать это к документации. И смотреть потом не в коде, а в документации.

(336) А вы таки распишите, как заполнять таблицу.

(337) Действительно! Чего бы нет. Почему бы ещё какой бесполезностью не позаниматься, лишь бы работу не делать!
Вы реально и в жизни настаиваете на использовании бестолковых действий, бесполезных вещей? Или только тут троллите?

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

(339) Вашими устами да мед пить.

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

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

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

(343) "Чушь собачья"! (с) (342)
Спагетти читаешь и читаешь себе, без прыжков. Всё в одном.
Вот если одно-второе Если на 100500 экранов растягивается и начинаются прыжки к разным точкам ветвления для сравнения условий - вот это да, это, прям, беда-а

(344) выше уже обсуждали, что есть понятие количества точек принятия решения на одну процедуру. Чем больше точек принятия решения, тем сложнее для восприятия процедура. Это аксиома. Машине пофиг, она и 100-кратное вложение циклов и условий переварит, а человеку сложно (БЫСТРО!) понять, чего там делает эта программа. Обычно большие процедуры выглядят так:
Процедура ВыполнитьЧегоТоТам()
    
    // много кода
    Если <Условие> Тогда
        Если <Условие> Тогда
            Для каждого  Из  Цикл
                Если <Условие> Тогда
                    // много кода
                    Для каждого  Из  Цикл
                        // много кода
                        Если <Условие> Тогда
                            // много кода    
                        Иначе    
                            // много кода    
                        КонецЕсли;    
                        
                    КонецЦикла;     
                    // много кода
                КонецЕсли;             
            КонецЦикла;
        Иначе    
            Для каждого  Из  Цикл                
                Если <Условие> Тогда
                    // много кода    
                Иначе    
                    // много кода    
                КонецЕсли;                
            КонецЦикла;
        КонецЕсли;
        // много кода
    ИначеЕсли <Условие> Тогда        
        Для каждого  Из  Цикл
            // много кода
            Если <Условие> Тогда
                // много кода    
            Иначе    
                // много кода    
            КонецЕсли;     
            // много кода
        КонецЦикла;     
    КонецЕсли;
    
КонецПроцедуры

только гораздо растянутее. Без многократного прогона отладчиком такой код понять почти невозможно. А это уже само по себе индикатор чрезмерной сложности

(345) знакомые конюшни, потянуло навозом :)

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

(347) Чем лаконичнее - тем лучше, потому что быстрее, значит - эффективнее, т.е. - дороже

(215) Благодарю за инфу

(32) Про термин метод. На 9:10 https://youtu.be/j-zS42qRv88?t=550

(350) А в текстовом виде?