Как форматировать код в 1С: практическое руководство

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

В экосистеме 1С есть два основных инструмента: встроенное автоматическое форматирование в конфигураторе и более гибкие механизмы в 1C:Enterprise Development Tools (EDT). Оба позволяют привести отступы, переносы строк и расстановку пробелов к единому виду одной командой, но настраиваются и ведут себя по-разному.

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

Зачем форматировать код и какие правила действуют в 1С

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

Фирма «1С» публикует стандарты разработки, которые описывают оформление модулей: структуру области программного интерфейса и служебных процедур, правила переноса длинных выражений, отступы в один символ табуляции, расположение операторных скобок и комментариев. Эти стандарты де-факто являются отраслевой нормой, и большинство команд либо принимает их целиком, либо использует как основу собственного соглашения.

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

Автоматическое форматирование в конфигураторе

В классическом конфигураторе форматирование встроено в текстовый редактор модулей. Откройте нужный модуль, выделите фрагмент кода (или ничего не выделяйте, чтобы обработать модуль целиком) и выполните команду из меню «Текст» — «Блок» — «Форматировать». Редактор выровняет отступы по вложенности конструкций и приведёт текст к правилам, заданным в настройках.

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

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

1. 1
   Откройте модуль объекта, формы или общий модуль
2. 2
   Убедитесь, что в параметрах задана единая ширина табуляции
3. 3
   Выделите фрагмент или оставьте модуль без выделения для полной обработки
4. 4
   Выполните «Текст → Блок → Форматировать»
5. 5
   Проверьте результат: отступы соответствуют вложенности, код компилируется без ошибок

Форматирование в 1C:EDT

В 1C:EDT форматирование выполняется комбинацией клавиш Ctrl+Shift+F либо через контекстное меню редактора — «Source» — «Format». Можно отформатировать выделенный фрагмент или весь модуль. EDT унаследован от платформы Eclipse, поэтому настройки форматирования собраны в профилях и позволяют задать значительно больше параметров, чем конфигуратор.

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

Практическая особенность EDT — интеграция с системами контроля версий. Если команда работает через Git, единый профиль форматирования критичен: без него каждый коммит будет содержать массу «шумовых» изменений отступов, и разобрать реальные правки станет почти невозможно.

Ручные правила оформления, которые не заменяет автоматика

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

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

Комментарии размещаются над поясняемым блоком с тем же отступом, что и код. Комментарий должен объяснять «почему», а не пересказывать «что делает» строка — очевидные комментарии вида «увеличиваем счётчик на единицу» только засоряют модуль.

Перенос длинных строк

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

Пустые строки

Пустая строка отделяет логические блоки внутри процедуры: подготовку данных, основную логику, обработку результата. Две и более пустые строки подряд внутри одного блока — признак того, что процедуру стоит разделить на несколько.

Форматирование в командной разработке и хранилище

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

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

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

Маршрут решения

Как выбрать действие

Модуль редактируется только вами и правки точечныеФорматируйте только изменённый фрагмент

Команда переходит на единые правила оформленияВыполните полное форматирование отдельным коммитом без функциональных изменений

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

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

Проверка результата и контроль качества

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

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

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

Контрольные точки

Как проверить результат

Синтаксический контроль модуля

Норма

Ошибок нет, модуль компилируется

Тревожный признак

Появились ошибки в строках, где был многострочный литерал

Просмотр diff перед коммитом

Норма

Изменены только отступы и переносы в ожидаемых местах

Тревожный признак

Затронуты строки, которые вы не редактировали

Отступы при открытии у коллеги

Норма

Структура выглядит одинаково на разных машинах

Тревожный признак

Код «плывёт» — смешаны табуляция и пробелы

Частые вопросы

Меняет ли автоформатирование логику программы?

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

Какая горячая клавиша форматирует код в 1C:EDT?

Ctrl+Shift+F форматирует выделенный фрагмент или весь модуль, если выделения нет. Та же команда доступна через контекстное меню редактора в разделе «Source».

Что выбрать для отступов — табуляцию или пробелы?

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

Можно ли настроить форматирование одинаково для всей команды?

Да. В 1C:EDT профиль форматирования настраивается в параметрах редактора и передаётся коллегам, а в конфигураторе согласуются параметры редактирования через «Сервис» — «Параметры». Соглашение стоит зафиксировать письменно.

Нужно ли форматировать весь модуль перед каждым коммитом?

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

Что делать, если после форматирования модуль перестал компилироваться?

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