Как правильно форматировать запросы в 1С: вручную или автоматически?

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

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

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

Основные плюсы штатного конструктора:

1. Гарантия синтаксической корректности. Если конструктор открыл и закрыл запрос без ошибок, значит, синтаксис верен.
2. Единообразие. Весь код в конфигурации будет выглядеть одинаково, что упрощает работу команды.
3. Скорость. Быстрое добавление таблиц, связей и условий без необходимости помнить точные имена полей.

Однако у конструктора есть существенные недостатки, которые заставляют программистов искать альтернативы. Рассмотрим их. Во-первых, конструктор безвозвратно удаляет комментарии внутри текста запроса. Это критично для сложных алгоритмов, где пояснения необходимы для понимания логики. Во-вторых, он не всегда справляется с «красивым» выравниванием синонимов (алиасов) по правой стороне, что делает список полей в секции ВЫБРАТЬ менее читаемым.

Проблема сравнения версий (Diff)

Важный аспект, который мы должны учитывать при выборе стиля форматирования, — это последующая поддержка кода. Если один разработчик навел «красоту» вручную (выровнял запятые, добавил пустые строки), а второй открыл этот запрос конструктором, то при сравнении модулей (например, в Git или через стандартное «Сравнение/Объединение») система покажет 100% изменений в тексте запроса. Проанализируем ситуацию: среди сотен строк визуальных изменений будет крайне сложно найти ту единственную логическую правку (например, изменение условия в ГДЕ), которую реально внес коллега.

Именно поэтому многие опытные разработчики рекомендуют не увлекаться ручным форматированием после конструктора. Чтобы минимизировать проблемы при сравнении в Git, можно использовать специальные параметры, игнорирующие изменения пробелов:

git diff -Xignore-all-space
git diff -Xignore-space-change

Когда конструктор бессилен: сложные конструкции

Существуют ситуации, когда мы вынуждены писать и форматировать запросы руками, так как стандартный конструктор просто не может их «переварить». Рассмотрим примеры таких конструкций:

1. Использование символа «звездочка» при помещении во временную таблицу из параметра-таблицы: ВЫБРАТЬ * ПОМЕСТИТЬ ВТ_Данные ИЗ &Т КАК Т; Такой запрос успешно выполнится объектом Запрос, но конструктор выдаст ошибку.
2. Отсутствие явного приведения типов в сложных объединениях, где платформа сама справляется с определением типа, а конструктор требует использования функции ВЫРАЗИТЬ().

В таких случаях ручное форматирование становится единственным выходом. Рекомендуется придерживаться стандартов 1С: каждое поле и каждое условие — с новой строки, ключевые слова — капсом.

Инструментарий для продвинутого форматирования

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

1. Инструменты разработчика (ИР) от Tormozit

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

• Вызов автоматического форматирования по ALT + SHIFT + F.
• Сохранение комментариев. В отличие от штатного конструктора, ИР умеет бережно относиться к комментариям разработчика.
• Интеллектуальное выравнивание псевдонимов и условий.
• Свой конструктор, который понимает больше синтаксических конструкций, чем стандартный.

2. EDT (Enterprise Development Tools)

Современная среда разработки на базе Eclipse предлагает гораздо более гибкие настройки форматтера. Выясним, что она дает уже сегодня:

• Возможность настройки профилей форматирования для встроенного языка и запросов.
• Автоматическое выравнивание кода при сохранении.
• Расширяемость: благодаря архитектуре плагинов, в EDT можно встраивать собственные форматтеры (например, на базе BSL Language Server).

3. Снегопат (Snegopat)

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

Практические рекомендации по оформлению

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

1. Имена таблиц и полей. Даем осмысленные имена. Вместо ВТ1 используем ВТ_ОстаткиНоменклатуры. Префикс ВТ_ помогает сразу понять, что работа идет с временной таблицей.
2. Секция ГДЕ. Группируем условия логически. Параметры, ограничивающие выборку по основным измерениям (Организация, Период), лучше ставить в начало.
3. Выравнивание. Если вы пишете запрос руками, старайтесь выравнивать ключевые слова по левому краю, а псевдонимы полей — в одну колонку. Это облегчает быстрый просмотр списка полей.
   Скопировать код

   
   ВЫБРАТЬ
       Продажи.Номенклатура           КАК Номенклатура,
       Продажи.КоличествоОборот       КАК Количество,
       Продажи.СуммаОборот            КАК Сумма
   ИЗ
       РегистрНакопления.Продажи.Обороты(&Начало, &Конец) КАК Продажи
   

4. Комментарии. Если запрос сложный, используйте комментарии перед текстом запроса в модуле, описывая, что делает каждый пакет. Если же вы используете ИР, можно оставлять комментарии прямо внутри текста.

Использование внешних редакторов (VS Code)

Многие разработчики сегодня предпочитают копировать текст запроса в Visual Studio Code, форматировать его там с помощью плагинов для BSL и возвращать обратно. Это позволяет использовать всю мощь современных форматтеров, таких как bsl-language-server, который поддерживает строгие стандарты оформления и позволяет настраивать даже такие мелочи, как положение запятой (в начале или в конце строки).

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