Как правильно использовать короткие процедуры и функции в 1С для повышения читаемости кода?

← На главную

В среде разработчиков 1С существует давняя проблема — так называемые «процедуры-портянки». Это огромные блоки кода на несколько сотен или даже тысяч строк, внутри которых перемешаны запросы, расчеты, работа с интерфейсом и запись в базу данных. Сопровождать такой код крайне сложно: даже небольшое изменение может привести к непредсказуемым ошибкам в других частях системы. В этой статье мы разберем принципы создания качественных методов, опираясь на опыт классиков программирования (М. Фаулер, С. Макконнелл, Р. Мартин) и специфику платформы 1С.

Почему длинные методы — это «технический долг»?

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

Высокая когнитивная сложность. Человек может удерживать в памяти одновременно около 7 объектов. Если в процедуре 20 переменных, мозг перестает видеть картину целиком.
Трудности отладки. Чтобы проверить маленькое условие в середине «портянки», приходится прогонять через отладчик весь гигантский алгоритм.
Отсутствие повторного использования. Код, «зашитый» глубоко внутри большой процедуры, невозможно вызвать из другого места без копипаста.

Принцип самодокументируемого кода

Разберем, как декомпозиция (разделение на части) помогает сделать код понятным без комментариев. Посмотрим на пример расчета НДФЛ. Вместо того чтобы писать все условия в одном месте, проанализируем следующий подход:


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

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

Борьба с избыточной вложенностью

Одной из главных метрик сложности кода является степень вложенности циклов и условий. Проанализируем ситуацию, когда код «убегает» далеко вправо из-за многочисленных Если ... Тогда и Для каждого ... Цикл. Хорошим тоном считается вложенность не более 2–3 уровней.

Рассмотрим пример плохого кода:


Процедура ОбработатьДанные()
    Если Условие1 Тогда
        Для каждого Строка Из Таблица Цикл
            Если Условие2 Тогда
                Для каждого Элемент Из Массив Цикл
                    Если Условие3 Тогда
                        // Слишком глубокая вложенность!
                    КонецЕсли;
                КонецЦикла;
            КонецЕсли;
        КонецЦикла;
    КонецЕсли;
КонецПроцедуры

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

Разберем улучшенный вариант:


Процедура ОбработатьДанные()
    
    Если Не Условие1 Тогда
        Возврат;
    КонецЕсли;
    
    Для каждого Строка Из Таблица Цикл
        Если Не Условие2 Тогда
            Продолжить;
        КонецЕсли;
        
        ОбработатьЭлементыМассива(Строка.Массив);
    КонецЦикла;
    
КонецПроцедуры

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

Оптимальный размер метода: один экран

Выясним, какой длины должен быть метод. Большинство экспертов сходятся во мнении: процедура в идеале должна умещаться на один экран монитора (примерно 25–50 строк). Если метод не влезает в экран, это сигнал о том, что он делает слишком много вещей одновременно (нарушает принцип Single Responsibility).

Стив Макконнелл в книге «Совершенный код» указывает, что методы до 200 строк не всегда являются ошибочными, но к ним нужно относиться настороженно. В 1С, учитывая многословность языка, порог в 50-70 строк является разумным компромиссом.

Области (#Область) против Процедур

В платформе 1С есть механизм #Область. Некоторые разработчики используют их, чтобы визуально скрыть «портянку». Однако важно понимать различие:

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

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

Практические советы по именованию

Помните, что имя метода — это его документация. Рассмотрим несколько правил:

Глагол + Существительное. Например: РассчитатьСкидку(), ЗаполнитьТаблицуОстатков().
Точность. Вместо ВыполнитьДействие() лучше написать ПроверитьЗаполнениеОбязательныхПолей().
Избегайте сокращений. В 1С принято писать полные имена. СформироватьДвиженияПоРегиструПродажи() гораздо лучше, чем СформДвиж().

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