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

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

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

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

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

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

(с) М.Фаулер

Так и есть.

Процедура в идеале должна влезать на один экран.

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

Первое правило: функция должна быть компактной. Второе правило: функция должна быть ещё компактнее!

(с) Р.Мартин

(0) приведешь, может, цитаты, где Макконел и Мартин это говорят? Чо-т я не помню ничего такого вообще совсем, хотя читал обоих

(4) это понятно

а, речь про количество кода внутри метода, а не про имя.
Да, все верно. Нормальная процедура/функция должна умещаться на один экран. Если не умещается, значит - бей на части. Хотя бы просто из уважения к коллегам

(6) Макконела чуть сложнее процитировать, он не говорит о коротких методах в одном месте, но подводит к этому во многих местах

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

(с) С.Макконел

Мартин - писатель довольно спорный. В его книгах не меньше 50% воды просто, чтобы книжка на полке стояла и не падала. Но есть и вполне дельные мысли у него.

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

(12) В каждом конкретном случае - решается индивидуально.
Пригать по микрофунуциям типа -
СоздатьПараметрыЗапроса()
ТекстЗапросаДляЗагрузки()
ОбъектЗапросДляЗагрузки()
ИсполнитьЗапрос()
ОбработатьРезультатЗапроса()
Тоже может быть то еще приключение.
В каждом конкретном случае - индивидуально, если мне понятен текст программы и он целостен - дробить не имеет смысла.
Если есть скрытые зависимости - тут без дробления никуда  не деться.

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

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

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

Код функции должен умещаться в один экран. В один экран терминала 80х25.

теперь я понял, почему я генерирую адов говнокод с очень длинными функциями на 5-6 экранов FullHD. Раньше удивлял чужой код на яве/си/си++, почему у них функция в функции, функции, функции, а там уже черт разбире, почему туда зашел...
на 1С я реализую поток сознания, потом забываю/забиваю с разбиением, потому что это ИМХО слабодисциплинирующий ЯП, с большими допусками.
на яве (делаю андроид проэкты) все разбито по классам и функциям, иногда в классе 20-30 методов и свойств, несложный проект состоит из 10+ классов

(17) 72*24

(13) дробить всё по микрофункциям не надо. Имя метода должно четко отражать его цель, чтобы сразу было понятно, что делает этот метод. Тогда не придется проваливаться в каждую процедуру/функцию без надобности. Например, есть функция:

Функция РассчитатьНДФЛПоСотруднику(Сотрудник, Параметры)
    
    НДФЛ = 0;
    
    ЯвляетсяРезидентом = СотрудникЯвляетсяРезидентомРФ(Сотрудник);
    
    Если ЯвляетсяРезидентом Тогда
        
        НДФЛ = РассчитатьНДФЛПоСтавке13(Сотрудник, Параметры);
        
    Иначе
        
        НДФЛ = РассчитатьНДФЛПоСтавке30(Сотрудник, Параметры);
        
    КонецЕсли;
    
    Возврат НДФЛ;
    
КонецФункции

в данной функции всего один блок "Если" и вызов трёх функций. Из кода сразу становится понятно, что он делает. Функция довольно короткая. Казалось бы, что можно было содержимое функций РассчитатьНДФЛПоСтавке13() и РассчитатьНДФЛПоСтавке30() впихнуть прямо здесь. Но! Тогда самодокументируемость кода снизилась бы

Функция РассчитатьНДФЛПоСотруднику(Сотрудник, Параметры)
    
    НДФЛ = 0;
    
    ЯвляетсяРезидентом = СотрудникЯвляетсяРезидентомРФ(Сотрудник);
    
    Если ЯвляетсяРезидентом Тогда
        
        // тут много кода
        //...
        
    Иначе
        
        // тут много кода
        //...
        
    КонецЕсли;
    
    Возврат НДФЛ;
    
КонецФункции

Допустим, я изучаю алгоритм расчета НДФЛ по ставке 30%. Если будет первая функция, то мне понадобится секунда, чтобы пробежать глазами 3 строки и нырнуть в нужную мне функцию РассчитатьНДФЛПоСтавке30(). А если бы вместо вызова этих функций было по 20-30 строка кода, как во второй функции? Тогда я сначала потратил бы время на просмотр первого блока кода (между Если и Иначе), и только потом, поняв логику кода, обнаружил что мне нужно идти дальше. Считай затрачено дополнительное время и лишние мыслительные ресурсы.

(20) когда ты "нырнешь" в РассчитатьНДФЛПоСтавке30 там 10 функций из четырех модулей будут собирать запрос и появится желание почитать умные книжки про фанатизм

+(20) тут можно возразить, что достаточно добавить под "Если" и "Иначе" по комментарию, и сразу станет всё понятно. Так, да не совсем так. Даже если я наткнусь на комментарий, мне всё равно придётся немного напрячь своё внимание и потратить немного времени, чтобы найти, где заканчивается ознаменованный комментарием участок кода и начинается другой. По сути я затрачу немного своих интеллектуальных ресурсов на тот код, который мне в принципе не нужен.
К тому же, с комментариями часто также творятся ахтунги

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

Я видел громоздкие процедуры/функции, авторы которых безолаберно подходили к именованию переменных и не считали нужным писать комментарии. Работать с такими методами это адский ад. Сначала два часа сидишь выясняешь, чего там в этом коде делается, на три раза прогоняешь всё отладчиком, чтобы понять логику. Вносишь маленькие изменения... и потом ещё три часа отлаживаешь этот метод. Ибо изменение одной строки кода привело к тому, что всё посыпалось в трёх других местах. Было бы всё по-человечески, понадобилось бы 5 минут, а так ушло 5 часов.

в 1с использование областей позволяет улучшить читабельность без увеличения кол-ва процедур

(0) Огромные процедуры и функции - как чукотские песни: нет в них ни конца ни края... И общую логику понять очень сложно..

"название должно быть четким и точным, раскрывающим суть метода" // 100%
"по-возможности должны быть небольшими" // По возможности

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

(25) согласен. Но всё-таки области нельзя рассматривать как замену выделению процедур/функций.
1. При вызове метода, передаваемые в метод параметры могут давать дополнительную поясняющую информацию. В то же время имя области не поясняет, с какими переменными работает код, спрятанный внутри этой области. Может появиться соблазн заглянуть внутрь области, когда будь на её месте процедура, желания не возникло бы
2. Если области по-умолчанию не сворачиваются, то область будет выполнять скорее функцию комментария, чем "указателя в оглавлении книги". Стандартно у всех области не сворачиваются, этот параметр нужно включать вручную.
3. Области позволяют сделать код легче воспринимаемым, но не позволяют сделать его более гибким. Если громоздкую процедуру исполосовать областями, она останется всё той же громоздкой процедурой, со всеми вытекающими. А компактные методы привлекательны ещё и тем, что такой код легче дорабатывать

(29) да никто и не спорит
зы: термин "метод" не совсем корректно используешь

"В старых языках программирования вызов процедур был связан с большими накладными расходами, которые удерживали программистов от применения маленьких методов"

А что чтото кардинально изменилось со времен когда в процедуру параметры передавали через стек? Или автор сего труда хочет сказать что "гигагерцы всё простят"?

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

(30) почему не правильно? Насколько я знаю, метод это общее название для процедур и функций

(29) "Стандартно у всех области не сворачиваются, этот параметр нужно включать вручную" // Стандартно все свернуто

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

(12) Ну вот в БСП частенько стек из 20 вложенных функций, мало вам? Надо 50?

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

(35) не, мне много. Вложенность функций не должна вредить их восприятию

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

(32)
> Насколько я знаю, метод это общее название для процедур и функций.
Нет.

(35) Это стандартная проблема функционального программирования по сравнению с ООП.

(39) кхм. А как правильно тогда?

(41) Функция/процедура.
Обычно функция. Если хочешь подчеркнуть, что она не возвращает значение - то процедура.
А метод - это процедура(функция)-член класса.

(42) В каком то смысле в платформе 1С функции/процедуры находятся или всегда в модуле (общем, формы, объекта или менеджера).

Так что можно считать что модуль ~ класс, ведь обращение извне идет через ".".
Короче функция/процедура это де юре метод модуля.

(43) ты тока в приличном обществе такое не говори)

(17) У нас процедуры :p

(24) 3000 рэ за час. Лучше срубить 5 часов.

(29) Ковырял я как то модуль формы на 150 к строк.
Трешман еще тот, синтакс помошник - отключал иначе работать нельзя было, и то в одном случае он все равно срабатывал и где то на минуту зависон.
Ну дык вот к чему я это - на исправление 2 строчек кода у меня ушел месяц.
Это было мое задание на ИС, то есть предпологалось что это займет 3 месяца.
Потом конечно по общим модулям раскидали, что возможно, стало лучше.

К чему я это.
Имея Легаси - будь готов за него платить.

https://habr.com/ru/post/429946/ просто оставлю это тут.

(0) Масса врачей считает, что нужно чистить зубы
Ну и, чтобы два раза не вставать, многие считают, что лучше быть здоровым и богатым, чем бедным и больным

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

(3) на 1 экран не возможно впихнуть текст запроса на 5 экранов, а дробить текст запроса - бред...

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

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

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

(50) "(0) процедура должна быть закончена по смыслу и понятна названа, все остальное - пофигу... " ну вот 1с 77, процедура формирования отчета СформироватьОтчет, закончена по смыслу и понятно названа, вот только содержит в себе 14 000 строк кода, из которых 10500 это дубли кода, удаление которых не повлияли никак на функционал. еще около 1000 строчек кода это заполнение полтора десятка идентичных по своей структуре таблиц значений. Добавление одной колонки в таблицу значения требовало до 8 часов затрат. Вынос заполнение строки тз в отдельную процедуру с переписыванием вызовов сократило это время до получаса.

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

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

Недоделанные отчёты - не беда. Главное - доделывайте детей. А то они вырастают и приносят недоделанные отчёты. И никак не разорвать этот порочный круг.

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

Вариант №1:

ОтсортироватьМассивПоВозрастанию(Массив);

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

Вариант №2

УпорядочитьКорректно(Массив);

Что упорядочить? Что подразумевается под "корректно"? Будут упорядочены значения массива или массив служит вспомогательным параметром? И ещё ряд вопросов. Хотя имя процедуры написано без ошибок, даже грамотными словами, оно совершенно не отражает цели процедуры. Придётся провалиться в эту процедуру, чтобы понять логику её работы

(55) А теперь попробуйте сделать что-нибудь реальное в 1С - там названия будут как Л.Н. Толстого предложения. Опять же, непонятно, по какому полю сортируется массив, так что провалиться все равно придется.

(55) ОтсартероватьМасивПоВозростанию код такой процедуры придется вычитывать в 99 случаях из 100. Потому что она может вернуть ТЗ, там может быть .Записать(), преобразованы типы и вообще что угодно. Всё пропорционально, сколько человек потратил усилий на имя, столько же и на код. Как человек задал вопрос, настолько он ему и важен.

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

(56) если код написан не говнокодером, то проваливаться не придется. Название процедуры и её единственный параметр и так рассказывают, что она выполняет.
Но если на данный момент ты читаешь говнокод, в котором процедура обозвана ВыполнитьДействия(), а там 3 тысячи строк кода, 10 различных логических действий, мёд, говно и пчёлы, то тебе придется заглянуть в подобную процедуру. Ибо в говнокодерстве принято выполнять в одной процедуре что угодно и как угодно, без какого-либо логического разграничения, а процедуры именовать скудно.

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

+ а орфографические ошибки могут происходить машинально. Очепятки там всякие, например

(58) Так по какому полю массива выполняется сортировка?

(60) скорее всего в массив переданы данные примитивного типа. Дальше всё очевидно.

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

Добавлю также правило от себя, про которое почему-то никто не пишет:  Без фанатизма.

попалось от того же Мартина
— Almost all the successful microservice stories have started with a monolith that got too big and was broken up
— Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious troubl.
Вполне переносится по смыслу на трехстрочные функции. Так что сам Мартин живет без фанатизма

(60) У массива одно поле.

(0) Согласен.

(61) В случае 1С там почти гарантировано не примитивный тип. Зачем сортировать строки или числа без привязки к чему-либо?

(64) Только это поле сортировать бессмысленно.

(38) За последний месяц-два несколько раз ставил с нуля платформы-сервера. Циклы и условия не сворачиваются, а вот области везде в открываемых конфигурациях (в модулях) _вроде_ были свернуты (т.к. Я запомнил стремное чувство от того, что приходилось их разворачивать в каждом модуле).
Но вот сейчас проверил в очередном "нулевом" конфигураторе и походу ты прав - области не свернутые)

(62) >> что люди не понимают, что и зачем делают
Откуда у вас такие выводы за всех? Это обман в явном виде.

(46) Самописка какая-то или в тиражной (типовой / отраслевой) конфе такое было?

(66) "зачем сортировать", "бессмысленно" - сортировать надо чтоб обойти потом конечно же

(69) самописка, дикий 15 летний Легаси, который построчно был переведен с 77 на УФ.

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

Но это не отменяет необходимости понимать, что ты делаешь вообще, в каких случаях такой подход применим, а в каких - нет.

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

(73) Главное, чтобы название процедуры не было больше самого кода процедуры :)

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

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

// Как правильно писать    код?
    //
    // ТАК:
    
    
    Выборка = Запрос.Выполнить().Выбрать();
    
    
    Пока Выборка.Следующий() Цикл
        
        УсловиеВыполнено = ПроверитьУсловие();
        
        Если УсловиеВыполнено Тогда
            
            // здесь много кода записанного через строчку, очень-очень важного и сложного
            ...
            
                        
            
        Иначе
            
            // здесь какой-то код, тоже через две строки, хотя простого, но очень важного
            ...
            
            
            
        КонецЕсли;
        
        
    КонецЦикла;

    
    // ИЛИ ТАК:    
    
    Выборка = Запрос.Выполнить().Выбрать();
    Пока Выборка.Следующий() Цикл
        Если УсловиеВыполнено() Тогда ДелаемЧтоТоВажное(); Иначе НичегоНеДелаем(); КонецЕсли;
    КонецЦикла;

(77)
так, в одну строку, точно делать не нужно:
Если УсловиеВыполнено() Тогда ДелаемЧтоТоВажное(); Иначе НичегоНеДелаем(); КонецЕсли;

Вот так:

Выборка = Запрос.Выполнить().Выбрать();
    Пока Выборка.Следующий() Цикл
        Если УсловиеВыполнено() Тогда
            Делаем...
            Делаем...
            Делаем...
            КонецЭкранаБлизокПередаёмПродолжениеВыполненияДелВПодпрограмму(Выборка, Объект, ПеременнаяПроцедуры1, ПеременнаяПроцедуры2, ПеременнаяПроцедуры3, ПеременнаяПроцедуры4, ПеременнаяПроцедуры5, ПеременнаяПроцедуры6, ПеременнаяПроцедуры7, ПеременнаяПроцедуры8... ПеременнаяПроцедурыН);
        Иначе
            НичегоНеДелаемВОтдельнойПодпрограммеТКУжеБылДостигнутКонецЭкрана();
        КонецЕсли;
    КонецЦикла;

Недавно надо было отловить ошибку в БП3 по имущественному налогу. В рот мне ноги... Это пишут не люди.

"..., а БОГИ!" - хочется добавить)

(77) Иногда второй вариант предпочтительней.
К примеру, есть какая-то функция общего назначения, называется
ЭлементЕстьВСтруктуре(Структура, Элемент), возвращает Булево.

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

И тогда правильнее было бы результат ЭлементЕстьВСтруктуре() разместить в переменной
СкладРазрешен = ЭлементЕстьВСтруктуре(), чтобы результат функции был понятен.

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

(79) это уже говнокод. Когда процедуры компактные и конкретные, в них просто нет зоопарка из переменных.

(83) Не видел такого кода, где нет зоопарка из переменных. Видимо, сложнее "СкладРазрешен = ЭлементЕстьВСтруктуре()" вы кода не видели. Если тема об этом, о том как прочитать "СкладРазрешен = ЭлементЕстьВСтруктуре()" и понять написанное - увы.

(83) >ещё один важный принцип: одна процедура для одной цели

я бы сказал, не "ещё один ...", а "_ОЧЕНЬ_ВАЖНЫЙ_ ..."
ну и цель цели тоже рознь. Очень часто программисты не задачу решают, а код пишут. Отсюда и названия методов, как в (79). И ОтсортироватьМассивПоВозрастанию() - из той же оперы.

(84) так в этом и весь вопрос, что бы разложить сложный код с зоопарком переменных на кучу простых функций типа "СкладРазрешен = ЭлементЕстьВСтруктуре()", тогда уменьшается объем кода и увеличивается его управляемость.

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

(87) "Да и понять что же делает каждый из 500 объектов тоже" так и идет обсуждение, что для понимания нужно правильно звать методы

(88) Ну и использовать методы не для того, чтобы только соблюсти правило "влезо на экран". Суть методов не в том, как в (79) описано. Чисто ради:
СуперСложнаяСортировкаЧастьОдин()
....
СуперСложнаяСортировкаЧастьДва()

так не надо.

В добавок ко всему, когда я изменяю функцию/процедуру, то я немного абстрагируюсь от окружающего кода. Если бы всё было в одной процедуре, то сможешь ли ты с первого раза ответить на вопрос:
"Где-нить эта переменная еще будет использовать?" Как в (86) сказали, управляемость намного выше становится.

bolobol не понимаю ход твоих суждений.

(88) само по себе 500 методов - это 500 методов, вне зависимости от назваания

(90) так не все ж 500 одновременно используются

(91) вызов конечной функции тянет за собой стек вызовов всех этих 500

ты на жаву взгляни
https://f2.tchncs.de/social.tchncs.de/media_attachments/files/000/442/176/original/dea7b2116b29c4b0.png

(93) дык, это если они у тебя вложенные одна в другую
А если у тебя Процедура ЗабубенитьСчастье()
В ней Если СчастьНет() Тогда
СделатьСчастье();
Иначе ОставитьНесчастливым() КонецЕсли; то у тебя в стэк попадет только одна из веток. Уже не 500, а 250 функций/процедур)

(93) авторы типовых видели этот скриншот и похоже решили "догнать и перегнать".

Уже было? http://govnokod.ru/24224

(96) Должен когда-нибудь выйти в люди один из разработчиков ЗУП и рассказать нам про выбранную архитектуру кода. Обосновать.

(97) Они не могут выйти - они к лавкам прикованы.

(84) а я видел. И стараюсь писать такой

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

(100) можешь привести пример из 500 методов в которых легко ориентироваться?

(100) когда стоит задача доработать 1 из методов - то да все легко.
Но как только есть ошибка в 1 из 5000. То ее нахождение - это архисложная задча

Как известно,
10% - написание кода, 90% - отладка (с)

(103) Что за цифры? Оторван контекст

(102) если код написан хорошо, в процедурах/функциях низкая связность*, то ошибка отыщется быстро. К слову, громоздкие процедуры совершенно не облегчают поиск ошибок. Ни на грамм. Наоборот, из-за обилия переменных внутри таких процедур, большого количества точек принятие решений, отладка такого кода сильно усложняется
(103) это только когда пишутся громоздкие процедуры. При нормальных условиях отладка будет составлять 10-30%.

(105) никто за громоздкие не топит. Везде должен быть соблюден баланс

(105) также никто не топит за располосование всего кода на микрофункции по 2-3 строки

(107) к (106)

(86) Это называется алгоритм.

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

(96) Это обычная попытка организации наследования.

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


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

но есть проблема интеллектуальная - грамотного именования методов. и типовые ут бп и зуп - на 70% примеры как не надо именовать (опять же из за раздутых библиотек в 500 методов).

(0) Есть ли способ автоматически определить самые длинные методы?

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

https://docs.microsoft.com/ru-ru/visualstudio/code-quality/ca1502-avoid-excessive-complexity?view=vs-2015

(114) Очень интересно! Хочу такое же в 1С... Если нет готового то я хотел бы это эээ разработать.

(115) думаю, это будет даже не сложно. Надо просто пересчитать все "И", "ИЛИ", "ПОКА", "ДЛЯ", "КОГДА" внутри одной процедуры.

Вот что про это пишет С.Макконел:
http://www.picshare.ru/view/9838185/

(115) Где-то я такое видел уже. Не на инфос*****те ли?

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

(105) ага.. в итоге у меня на тестировании по разным сценариям (вручную) я уже хз не помню был я в этойпроцедуре-функции или нет.. даже если она элементарная какая-нить.. потому что стек 500. В итоге отбиваю комментарием
//+++ ОТРАБОТАНО.

жпс полный короче

(105) При нормальных условиях отладка будет составлять 10-30%.
- это вы какие-то мелочи пишите.. я когда начинаю делать по уму - отладака занимает дофигища времени!

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

(121) http://catalog.mista.ru/public/166182/

оно?

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

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

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

В общем баланс рулит)

Кстати, при оценке сложности можно ориентироваться ещё на один важный параметр - вложенность циклов и условий друг в друга


нормально:

Процедура МояПроцедура()

    // Код
    //...
        
    Если <...> Тогда    
        // Код
        //...         
    Иначе        
        // Код
        //...    
    КонецЕсли;     

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

нормально:

Процедура МояПроцедура()

    // Код
    //...
    
    Для  <...>  Цикл     
        Если <...> Тогда        
            // Код
            //...            
        Иначе            
            // Код
            //...        
        КонецЕсли;    
    КонецЦикла;          

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

нормально:

Процедура МояПроцедура()

    // Код
    //...
        
    Если <...> Тогда    
        Для  <...>  Цикл    
            // Код
            //...    
        КонецЦикла;        
    Иначе        
        // Код
        //...    
    КонецЕсли;     

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

плохо:

Процедура МояПроцедура()

    // Код
    //...
        
    Если <...> Тогда    
        Для  <...>  Цикл    
            Если <...> Тогда
                Для  <...>  Цикл
                    // Код
                    //...    
                КонецЦикла;
            КонецЕсли;     
        КонецЦикла;        
    Иначе        
        Для  <...>  Цикл    
            Если <...> Тогда
                // Код
                //...    
            КонецЕсли;     
        КонецЦикла;    
    КонецЕсли;     

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

+(124) норма, это когда степень вложенности условий и циклов не более 2. "Цикл" внутри "Если", либо "Если" внутри цикла, либо "Цикл" внутри "Цикл", либо "Если" внутри "Если". Более глубокую вложенность можно считать сложным кодом. Вложенность можно посчитать по количеству табуляций внутри процедуры для самых "убегающих вправо" строк

Процедура МояПроцедура()    
    Если <...> Тогда    
        Для  <...>  Цикл    
            Если <...> Тогда
                Для  <...>  Цикл
                    //...
                КонецЦикла;
            КонецЕсли;    
        КонецЦикла;            
    КонецЕсли;    
КонецПроцедуры

в данной процедуре степень вложенности 4. Это слишком много. Визуально анализировать такой код тяжело. Да и отлаживать тоже не сказка

(125) Нефиг его анализировать. Если код работает, то нужно оставить его в покое.

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

(125) научи, как этого избегать?

(123) Так какую же длину методов считать приемлемой в объектно-ориентированных программах? Многие методы в объектно-ориентированных программах будут методами доступа, обычно очень короткими. Время от времени реализация сложного алгоритма будет требовать создания более длинного метода, и тогда методу можно будет позволить вырасти до 100–200 строк (строкой считается непустая строка исходного кода, не являющаяся комментарием). Десятилетия исследований говорят о том, что методы такой длины не более подвержены ошибкам, чем методы меньших размеров. Пусть длину метода определяют не искусственные ограничения, а такие факторы, как связность метода, глубина вложенности, число переменных, число точек принятия решений, число комментариев, необходимых для объяснения метода, и другие соображения, связанные со сложностью кода. Что касается методов, включающих более 200 строк, то к ним следует относиться настороженно. Ни в одном из исследований, в которых было обнаружено, что более крупным методам соответствует меньшая стоимость разработки, меньший уровень ошибок или оба фактора, эта тенденция не усиливалась при увеличении размера свыше 200 строк, а при превышении этого предела методы неизбежно становятся менее понятными.

(с) С.Макконел

(126) именно так и поступают многие разработчики. Хай последователи мучаются

(127) очевидно, вынося слишком "вложенный" код в отдельные процедуры и функции.

(126) так самое интересное начинается когда не работает или  нужно допилить

+(129) переделываем прежний вариант

Процедура МояПроцедура()    
    Если <...> Тогда    
        Для  <...>  Цикл    
            МояНоваяПроцедура();        
        КонецЦикла;            
    КонецЕсли;    
КонецПроцедуры

Процедура МояНоваяПроцедура()    
    Если <...> Тогда
        Для  <...>  Цикл
            //...
        КонецЦикла;
    Иначе
        //...
    КонецЕсли;    
КонецПроцедуры

проблемо решоно. А хорошие названия процедур будут только в помощь.

(131) А если там 10 переменных до условий? все их передавать далее?

или например сорировка пузырьком: там аж 2й цикл. срочно сделать еще 1 процедуру

(131) Идея правильная, но этим надо заниматься при уровне вложенности больше 20. При этом в отдельные процедуры надо выносить целые блоки где-то с уровня 10, а не самый нижний уровень.

(132) Сделать их глобальными!

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

(136) Это потому что средний уровень программистов снижается. Все эти одноклассники и вконтактики разрушают мозги. Сегодняшние студенты не могут понять вложенность 10-20, а вот раньше процедур и функции ВООБЩЕ НЕ БЫЛО. Мы всё писали внутри одного модуля и грамотно пользовались GOTO.

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

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

(128) Точно, оно.

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

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

А еще вложенность можно уменьшать и другими путями:

Процедура МояПроцедура()    
    Если Не <...> Тогда
        Возврат;
    КонецЕсли;    
    Для  <...>  Цикл    
        Если Не <...> Тогда
            Продолжить;
        КонецЕсли;
        Для  <...>  Цикл
            //...
        КонецЦикла;
    КонецЦикла;    
КонецПроцедуры

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

на асме только гото и есть

(137) дело не в мозгах, а в излишнем усложнении там, где его легко можно было избежать. Когда рулил код без процедур и со всякими GOTO, программы были более примитивными сами по себе. Операционки состояли из тысяч строк. Нынешние программы намного сложнее тех безпроцедурных динозавров. А методы, классы, инкапсуляции и иже с ними изобрели как средство, позволяющее разрабатывать программы огромной сложности. Так почему облегчающими жизнь инструментами не пользоваться? Если код можно сделать более легким для восприятия, почему бы этого не сделать?

(141) даже на асме есть вызов подпрограммы, типа call/ret. И в спектрумовском бэйсике для этого gosub был)

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

(142) ну ты такой молодец бьешься за повышение качества кода.
А твой сосед клепает как хочет. И что ты будешь делать?

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

(146) влом уделять "животным" - случайным людям в программировании.

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

В итоге вместо одной последовательной функции у нас их уже три, да еще и в файле расположат вторую выше первой)

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

(146) не обязательно влом, просто много людей не понимают и не знают. Понимание приходит с опытом

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

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

нет у них внутреннего чувства прекрасного

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

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

(154) ни разу не видел, чтоб кто-то (не в инете) распальцовывался

(151) код не форматируют это уже даже не студенты, это школьники какие-то)

(155) начнем с того что в 1с нет нормальных инструментов код ревью

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

(159) ты тим лид / начальник? визможность то есть "бить" ?

(158) В самой 1С да, но например на этом форуме кое у кого есть инструменты для перевода конфигурации в текстовые файлы и дальше уже можно использовать «взрослые» инструменты.

(160) была бы - бил бы, а так только мечтаю)

(120) Это потому что 2/3 - это проектирование и моделирование ;)

(161) какой % их юзает?
если тяжело смотреть на всех этих "школьников", то лучше из 1с уходить

(159) это и опытному не всегда просто, поэтому и получается что лучше оставить функцию в 200 строк как есть, чем думать как ее лучше поделить и рисковать сделать неудачно. При условии конечно что функция читаема и явных кандидатов на выделение нет.

(164) ну так я и ушел)

(165) ну и чтоб рефакторингом заниматься, это тесты нужны.
А их есть еще меньше чем нормального кода

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

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

(128) Размер должен быть таким, который может написать индус с уровнем Junior без обращения к старшим.

(137) А еще модифицировали код во время выполнения программы - у современных программистов от этого мозг взорвется :)

(170) индусу волю дай, он писать быстрее чем думает будет)

А еще циклы вручную разворачивали, что бы накладные расходы снизить..

(142) И чем эти монстрообразные программы лучше тех?

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

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

(171) Ну, подразумевается, что оно еще должно работать как надо :)

(172) Вот тут и проявляются плюсы 1С перед, скажем C# - проектирование уже в значительной мере сделано, документы, справочники, табличные части.. Остается только в обработчиках не сильно накосячить.

И C# - вот тебе база данных, дальше сам думай как это все реализовать. С одной стороны свобода. С другой - анархия)

(137) > Все эти одноклассники и вконтактики

Эй, эй, в прошлый раз это были алкоголь и наркотики! Не стоит так разко выходить из образа.

(175) С хорошим проектированием даже в типовых проблемы: обновлял на днях разные типовые - так там новые объекты уже имеют префикс "Удалить"...

(176) а чем по вашему одноклассники во вконтактиках занимаются)

(177) > даже в типовых проблемы

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

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

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

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

(0) просмотрел все твои посты, во всех кроме новогоднего отсылка к книгам, а тут ещё и ссылки на магазин. Скрытая реклама? ;-)

(177) Это еще хороша, когда есть "Удалить_". Недавняя УТ 11 повыкидывала кучу процедур из форм, удалила несколько общих модулей. Все это наложилось на косяк разработки, когда забывали ставить префикс перед новыми процедурами.
И вот ты сидишь и смотришь на изменения в модуле, где 25 процедур нет в новой конфе, вроде как удалить надо, а вроде и ссыкотно, где там типовая, а где добавленная разработчиками? И... оставляешь. А в них ссылки на несуществующие ныне модули. И ловишь ошибки при запуске. Ох и веселье было.

(180) что ж, теперь понятно почему мне совершенно не хочется бегать)

(185) Исписался == Забегался == Спился.

Так-то! (:

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

(173) и как давно наличие аккаунтов на разных интернет-ресурсах считается подтверждением опыта и мастерства?

(188) а как ты еще докажешь, что ты не х.. с горы?

(183) считаю ссылаться на книги хорошей практикой. Ну и не только на книги, я часто ссылаюсь на сайт ИТС

(189) доказать можно по-разному. Смотря кто будет оценивать

(188) ну хоть какое-то подтверждение Вашей опытности.

прочтение Макконела  и Фаулера Вас положительно характеризует, но не подтверждает Вашего опыта.

(184) вот кстати со «взрослыми» инструментами это вообще не проблема - отлично показывают что было удалено и что добавлено.

(193) Что-нибудь из этого списка https://en.wikipedia.org/wiki/List_of_tools_for_code_review
или может что-то другое конкретное можешь порекомендовать?

(для 1С)

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

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

программисты, которые пишут длинные процедуры и функции, компенсируют в коде недостаток длины в каких-то других местах.

(198) а у самого-то воон какая длинная полоска)

(199) Эту полоску не он рисовал...) Полагаю, есть другие места.

(196) "проблема что для работы всех этих инструментов нужно конфу в текстовые файлы перегнать, а после объединения обратно собрать файлы в конфигурацию" // Это Я понимаю. Вообще не проблема )

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

Я осознал тщетность бытия, когда в типовой прошелся на глубину в 5 процедур, в каждой из которых была 1!!! строчка вызова процедуры с ТЕМИ ЖЕ параметрами, и на полной глубине было 5 строчек, обрабатывающих эти параметры.

(203) Мб чота для совместимости перемудрили?

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

(205) А через 2 месяца "такой-то расчет" нужен еще в другом месте. А он там хардкоДными гвоздями к контексту прибит.

(206) вот тогда выносишь часть в функцию/процедуру и вызываешь ее в положенных местах

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

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

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

(209) ага, я вот время от времени в ЗиК лазю, печ.формы поправить. Так там по 8 - 10 копий одного и того же, в зависимости от условий. В одной процедурине на 100500 строк. Смотришь на это, и очень хочется кого-нибудь ударить. Больно.

(210) В том то и печаль, что скопипастить проще простого. Думать всегда сложнее.

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

(212) >> 10 функций вызываемых одна из другой тоже не гигантских умственных усилий требует

Но требуется больше, чем копипастить.

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

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

(205) >> выделать код в отдельную процедуру/функцию/метод нужно если он может и будет повторно использован из другого места.

Смысл процедур и функций в не только в этом.

(202) Ревью можно делать "по факту" - то есть смотреть в том же SourceTree историю последних изменений (не очень удобно, но жить можно)

Более продвинутый вариант - вообще не вливать изменения в основную ветку без ревью, тут уже gitlab сервер надо поднимать. Там можно запретить разработчикам коммитить в главную ветку - они создают отдельные ветки на каждую задачу, когда она выполнена - заводят на gitlab'е merge request, вот там gitlab показывает изменения, можно комментарии к ним писать, обсуждать что-то, и если все ок - одной кнопкой залить этот merge request в главную ветку.

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

(206) Это уже недоработка проектировщика.

(216) В наше время поголовного agile на проектировщика свалить становится все сложнее и сложнее)

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

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


http://catalog.mista.ru/public/789709/

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

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

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

(218) "8

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

(222) ни разу не слышал денормализация?
и получается хранени еитогов по регистрам - это ну его нафик?

(223) тогда уж и регистры - нафик! отчет по документам - прекрасен! :)

(223) а хранение итогов в регистрах это разве не дублирование дублирование информации в таблице текущих итогов и таблице итогов?

(224) вот вот) а то дублируют информацию в регистре и документах

(220) Согласен. Каждое утро открываешь в своём коде всё новое и новое. Частенько и неприятное ))

(226) это умное дублирование, платформа предоставляет средства для его поддержки в актуальном состоянии, так что регистры пусть живут)

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

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

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

(221) Лозунг "без фанатизма" - единственный, который я готов фанатично поддерживать :))

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

Не забываем, что вызов процедуры жрет время. Чем больше процедур, тем медленнее программа работает.

(232) это настолько ничтожно мало, что им можно пренебречь

(207) "вот тогда выносишь часть в функцию/процедуру и вызываешь ее в положенных местах"

На деле, когда сталкиваешься с громоздкими процедурами, вынести часть в отдельную процедуру/функцию затруднительно. Допустим, процедура 1000 строк, тебе нужно вынести в отдельную процедуру 20 строк. "Внезапно" оказывается, что переменные, используемые в этих 20-ти строках, инициализируются в строке №2, 15, 128, 136, 324... И крутишь ты колесико мышки туда-сюда, чтобы всё это добрище как-то собрать в одну кучу. А потом снова "внезапно" выясняется, что переменная ТаблицаНастроек, которую тебе нужно использовать в выделенной процедуре, инициализируется в строке №36, а потом меняется в строках №№ 124-128, 224 и 452, и вот ты уже материшь и проклянаешь писателя этой мегапроцедуры.

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

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

(233) Пренебречь? Да это главный источник тормозов, после кривых рук. Особенно вызов виртуальных методов.

(236) это в каких годах дело было? В 70-х?

Где-то читал про разработку какой-то компьютерной игры. Вроде даже популярной (я в них не играю, поэтому название не запомнил). Так вот, движок этой игры писался на С++, и при разработке движка царили жесткие стандарты. Одним из правил этих стандартов было ограничение на размеры методов. Не более 30 строк. Если в методе более 30 строк, разработчик должен отдельно обосновать длину каждого такого метода.

(237) Да это и сейчас актуально. Если нужно много данных лопатить, выкинуть лишние вызовы- очень полезно.

(236) Виртуальные методы в 1с? О_о
Где это такое чудо?

(240) в БСП же наверное?

(240) а шо только про 1с можно писать?

(242) а как тебе невиртуальный вызов
иначеесли врег(сокрлп(св.свойство))="УСЛОВИЕ" тогда
?

(233) Пренебрегает тут чуть-чуть, пренебрегаем там чуть-чуть - а в итоге получаем тормозное поделие...

(244) В современном мире есть инструменты для измерения. И есть понятие "допуски" (это больше к металлообработке, но тем не менее)

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

(241) Это где там такое?
(242) В контексте места обсуждения - лучше да.

(245) Ну и? Вот показывают они, что горячих точек нет. Тормозит все - соответственно, переписывать надо с нуля.

(247) Дословно не приведу сейчас, но куча мест, где что-то типа
Если ЕстьМетод(ПереопределяемыйМодуль.блабла) Тогда
    выполнить(ПереопределяемыйМодуль, "блабла")

(248) Если так, то да. Только при чём тут виртуальные вызовы? Это значит, что вся система - дерьмо.

(249) Это не вирутальный метод, это тупая рефлексия

(250) Да, но они так имитируют виртуальные вызовы. Отсюда и накладные расходы, несравнимые с нормальной технологией. Виртуальные вызовы в С++, напрмер, не отличаются ничем от невиртуальных, это я немножко знаю.

(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) А в текстовом виде?