Как составить стандарт оформления и соглашение по написанию кода в 1С

← На главную

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

Отказ от отрицаний в именах переменных и методов

Одной из распространенных ошибок при проектировании булевых переменных и функций является включение частицы отрицания прямо в их идентификатор (например, НеСоответствует, НеЗаполнено или НеЗначениеЗаполнено). Проанализируем, к чему это приводит на практике:

Рано или поздно при усложнении логики алгоритма в коде возникнет конструкция с двойным отрицанием:


Если Не НеЗначениеЗаполнено Тогда
    ВыполнитьДействие();
КонецЕсли;

Такой синтаксис существенно затрудняет восприятие логического условия и повышает вероятность ошибки. Рекомендуется всегда формировать имена предикатов в утвердительной форме: ЗначениеЗаполнено, СоответствуетУсловию, ДанныеКорректны. Отрицание должно задаваться исключительно оператором Не в самом выражении:


Если Не ЗначениеЗаполнено Тогда
    ВыполнитьДействие();
КонецЕсли;

Чистота функций и работа с выходными параметрами

Классический принцип проектирования «параметр функции не должен неявно возвращать значение» направлен на устранение побочных эффектов. В платформе 1С присутствует ряд встроенных методов, возвращающих значение через параметр по ссылке (например, метод Свойство у объекта Структура):


Значение = Неопределено;
Если СтруктураПараметров.Свойство("КлючПоиска", Значение) Тогда
    ОбработатьЗначение(Значение);
КонецЕсли;

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

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

Правила именования общих модулей и префиксы доработок

При доработке типовых конфигураций или внедрении собственной подсистемы критически важно соблюдать единую схему именования объектов метаданных. Недопустимо называть модули именем конкретного программиста или наименованием компании-интегратора (например, Франчайзи_ОбщегоНазначения). При смене исполнителя такой код создает проблемы и требует массового рефакторинга вызовов.

Рассмотрим правила формирования префиксов:

Языковая согласованность: используем тот же язык для префиксов, на котором ведется разработка в конфигурации. Если конфигурация выполнена на русском языке, избегаем латинских вставок без строгой необходимости.
Префикс подсистемы или проекта: формируем сокращенный префикс (2–4 символа), обозначающий функциональный блок или проект (например, инт_ для интеграций, внедр_ для проектных доработок).
Разделение по контексту исполнения: разносим код по специализированным общим модулям в зависимости от назначения: Префикс_ОбработчикиПодписокНаСобытия, Префикс_ОбщегоНазначенияКлиент, Префикс_ОбщегоНазначенияСервер.

Ограничение длины строк и правила форматирования

Для сохранения читаемости кода при вертикальном разделении экранов и проведении код-ревью в системах контроля версий принято соглашение: длина строки не должна превышать 120 символов.

Разберем правила переноса длинных конструкций:

Сложные логические условия: операторы И и ИЛИ переносятся на новую строку с выравниванием по левому краю условия:
```
Если ЭтоНовыйКонтрагент
    И Не Отказ
    Или ПринудительнаяЗапись Тогда
    ЗафиксироватьИзменения();
КонецЕсли;
```
Вызовы методов с большим числом параметров: каждый параметр переносится на отдельную строку со сдвигом вправо на один шаг табуляции.
Запросы: при ручной оптимизации текста запроса ключевые разделы (ВЫБРАТЬ, ИЗ, ГДЕ, СГРУППИРОВАТЬ ПО) выравниваются по левому краю, а вложенные поля переносятся со смещением.

Использование защитных условий (Guard Clauses)

Избыточная вложенность блоков Если ... Тогда ... КонецЕсли снижает читаемость кода («эффект лесенки»). Для упрощения структуры применяем паттерн досрочного выхода:


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

// Рекомендуемый вариант с защитными условиями
Процедура ПровестиПроверку(ДокументСсылка)
    Если Не ЗначениеЗаполнено(ДокументСсылка) Тогда
        Возврат;
    КонецЕсли;

    Если ДокументСсылка.ПометкаУдаления Тогда
        Возврат;
    КонецЕсли;

    ВыполнитьОсновнойАлгоритм(ДокументСсылка);
КонецПроцедуры;

Структурирование модулей по областям

В соответствии со стандартами разработки Библиотеки стандартных подсистем (БСП) программный код общих модулей и модулей менеджеров объектов разделяется директивами областей. Это формирует четкую архитектуру и упрощает навигацию:

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

Автоматизация контроля стиля в процессах разработки

Соблюдение соглашений об оформлении кода не должно контролироваться исключительно вручную. Для поддержания качества используем современные инструменты экосистемы 1С:

Среда разработки 1C:Enterprise Development Tools (EDT): среда содержит встроенные профили стиля кода (Code Style), валидацию именования, отображение вертикальной границы длины строки и автоматическое форматирование при сохранении.
Статические анализаторы в CI/CD: подключение специализированных линтеров сообщества на этапе пулреквестов позволяет автоматически отклонять коммиты, содержащие критические отклонения от стандартов (неправильные префиксы, избыточную вложенность, нерекомендуемые методы платформы).
Pre-commit хуки: запуск автономных утилит форматирования перед отправкой изменений в систему контроля версий гарантирует единообразие отступов и пробелов у всех участников команды.