При внедрении корпоративных стандартов разработки в командах 1С часто возникает множество споров. Одним из наиболее дискуссионных правил является ограничение длины одной процедуры или функции (например, лимит в 40 строк кода). Для разработчиков, привыкших писать монолитные процедуры с объемными запросами и циклами обработки на сотни строк, такое требование кажется абсурдным и нереализуемым.
В этой статье мы подробно разберем, действительно ли существует подобное ограничение в официальных стандартах фирмы «1С», откуда взялась цифра «40 строк», почему монолитный код усложняет жизнь коллективу разработки и как правильно декомпозировать логику, чтобы сделать ее понятной, тестируемой и удобной для сопровождения.
Проанализируем официальный раздел «Система стандартов и методик разработки конфигураций» на портале ИТС. Нам важно выяснить, зафиксировано ли там жесткое требование к количеству строк.
Прямого ограничения на физическое количество строк в теле одной процедуры или функции в стандартах ИТС нет. Однако фирма «1С» устанавливает другие жесткие смежные правила, которые косвенно подталкивают разработчиков к написанию компактных методов:
Таким образом, хотя «1С» официально не запрещает писать длинные процедуры, общая методология платформы направлена на создание лаконичных и узкоспециализированных методов.
Выясним происхождение этого правила. Лимит в 40 строк (в некоторых компаниях — 50 или 60 строк) пришел из классической методологии разработки программного обеспечения (в частности, из книги Роберта Мартина «Чистый код») и концепции «одного экрана».
Суть концепции проста: разработчик должен видеть весь текст процедуры на своем мониторе целиком, не прибегая к вертикальной прокрутке. Это позволяет мгновенно охватить взглядом всю логику метода, понять его назначение, локализовать переменные и алгоритм работы. С учетом шапки процедуры, комментариев и закрывающей конструкции КонецПроцедуры, чистый исполняемый код как раз укладывается в диапазон 30–40 строк на стандартном мониторе.
Главные аргументы в пользу коротких методов:
Рассмотрим распространенную ошибку, которую совершают программисты при попытке формально уложиться в стандарт 40 строк. Они берут длинную линейную процедуру на 120 строк и механически «нарезают» ее на три части, вызывающие друг друга последовательно.
Посмотрим на пример такого неудачного кода:
Процедура ВыполнитьРасчетИЗапись()
// Первые 40 строк кода (например, подготовка параметров)
...
ВыполнитьШаг2();
КонецПроцедуры
Процедура ВыполнитьШаг2()
// Следующие 40 строк кода (например, расчеты)
...
ВыполнитьШаг3();
КонецПроцедуры
Процедура ВыполнитьШаг3()
// Последние 40 строк кода (запись результатов)
...
КонецПроцедуры
Почему это плохо? Такой подход не только не улучшает читаемость, но и критически ухудшает ее. Читателю кода приходится постоянно прыгать по модулю («листать страницы взад-вперед»), чтобы восстановить в голове общую картину. Теряется контекст переменных, усложняется отладка.
Разберем, как сделать декомпозицию правильно. Архитектура должна строиться по принципу оркестрации: главная (вызывающая) процедура верхнего уровня описывает общую бизнес-логику («что мы делаем»), а вызываемые подчиненные процедуры реализуют технические детали («как мы это делаем»).
Спроектируем правильную структуру кода:
Процедура ВыполнитьРасчетИЗапись()
ПараметрыРасчета = ПолучитьПараметрыДляРасчета();
ТаблицаРезультатов = РассчитатьПоказатели(ПараметрыРасчета);
Если ПроверитьКорректностьДанных(ТаблицаРезультатов) Тогда
ЗаписатьРезультатыВБазу(ТаблицаРезультатов);
Иначе
ВызватьИсключение "Обнаружены ошибки при расчете показателей!";
EndIf;
КонецПроцедуры
Проанализируем этот пример. Сама процедура ВыполнитьРасчетИЗапись занимает всего 10 строк. Она великолепно читается, логика ясна с первого взгляда даже непрограммисту. Каждое действие вынесено в специализированную функцию:
ПолучитьПараметрыДляРасчета() — занимается только сбором исходных данных.РассчитатьПоказатели() — выполняет чистые математические расчеты.ПроверитьКорректностьДанных() — отвечает за валидацию.ЗаписатьРезультатыВБазу() — осуществляет транзакционную запись.Каждая из этих подчиненных процедур также будет лаконичной, легко читаемой и изолированной.
Основной аргумент противников коротких процедур в 1С — это массивные запросы (особенно в конфигурациях уровня ERP, ЗУП или Комплексной автоматизации) и сложные формулы расчетов себестоимости. Действительно, текст запроса может занимать сотни строк.
Разберем, как грамотно обрабатывать такие ситуации, сохраняя чистоту кода:
ПолучитьТекстЗапросаДляАнализаПродаж().МенеджерВременныхТаблиц.Если...ИначеЕсли прямо в цикле. Создайте вспомогательную функцию СтрокаТаблицыСоответствуетУсловиям(), передавайте туда текущую строку и возвращайте булево значение.Современная индустрия разработки на 1С давно ушла от ручного подсчета строк кода. В крупных проектах качество программного кода контролируется автоматически с помощью таких инструментов, как 1С:АПК (Автоматизированная проверка конфигураций) или связки SonarQube с плагином BSL Community.
В этих инструментах действительно есть правило проверки длины метода (MethodSizeLOC). По умолчанию в плагине BSL оно настроено на более лояльное значение (например, 75 или 100 строк), но компании могут ужесточать его до 40 строк.
Однако более прогрессивным и здоровым подходом считается контроль не физической длины кода, а его когнитивной сложности (Cognitive Complexity) и цикломатической сложности (Cyclomatic Complexity):
Если читается значительно проще, чем метод на 20 строк, содержащий 5 уровней вложенности циклов Для каждого и условий.Ограничение в 40 строк для процедур и функций в 1С — это не «бред», а признанная мировая практика написания чистого, тестируемого и надежного кода. Не стоит воспринимать его как жесткий механический запрет, заставляющий резать алгоритмы «по живому». Относитесь к этому правилу как к важному ориентиру, сигнализирующему о необходимости рефакторинга и декомпозиции логики. Правильное разбиение процедур повышает скорость командной разработки и снижает количество ошибок при обновлении и поддержке конфигураций.