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

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

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

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

Базовый синтаксис комментариев

Однострочный комментарий ставится либо на отдельной строке, либо в конце строки с кодом. Оба варианта корректны:

// Рассчитываем скидку по накопительной программе
СуммаСкидки = СуммаДокумента * 0.05; // базовая скидка 5%

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

В тексте запроса комментарии тоже работают через //. Это удобно для пояснения сложных соединений и условий:

Запрос.Текст =
"ВЫБРАТЬ
|   Продажи.Номенклатура КАК Номенклатура
|ИЗ
|   РегистрНакопления.Продажи КАК Продажи
|ГДЕ
|   Продажи.Период МЕЖДУ &НачалоПериода И &КонецПериода
|   // исключаем служебные документы корректировки
|   И НЕ Продажи.Регистратор ССЫЛКА Документ.КорректировкаРеализации";

Горячие клавиши для комментирования блоков

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

• Ctrl + Num/ — закомментировать выделенный блок (слеш на цифровой клавиатуре);
• Ctrl + Shift + Num/ — снять комментарий с выделенного блока;
• те же команды доступны через меню «Текст» → «Блок» → «Закомментировать / Раскомментировать».

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

1. 1
   Откройте модуль в конфигураторе и выделите нужные строки мышью или Shift+стрелки
2. 2
   Нажмите Ctrl+Num/ — в начало каждой строки добавится //
3. 3
   Для возврата кода выделите блок и нажмите Ctrl+Shift+Num/
4. 4
   Сохраните модуль (Ctrl+S) и проверьте, что конфигурация обновляется без синтаксических ошибок

Что и как стоит комментировать

Главный принцип: комментарий отвечает на вопрос «зачем», а не «что». Строка // увеличиваем счётчик на 1 перед Счетчик = Счетчик + 1 бесполезна — код и так это говорит. Полезный комментарий объясняет причину: // пропускаем первую строку файла — это заголовок колонок.

Заголовки процедур и функций

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

// Возвращает остаток товара на складе с учётом резерва.
//
// Параметры:
//   Номенклатура - СправочникСсылка.Номенклатура - товар для проверки.
//   Склад        - СправочникСсылка.Склады - склад отбора.
//
// Возвращаемое значение:
//   Число - доступный остаток, 0 если товара нет.
//
Функция ДоступныйОстаток(Номенклатура, Склад) Экспорт

Нестандартные решения и обходные пути

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

Комментирование доработок в типовых конфигурациях

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

// +++ Доработка: учёт комиссии эквайринга (задача 1142)
СуммаКомиссии = СуммаОплаты * 0.018;
СуммаКЗачету = СуммаОплаты - СуммаКомиссии;
// --- Конец доработки

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

Комментирование как способ отладки: ограничения

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

Для отладки часто удобнее точки останова и пошаговое выполнение (F5, F11, Shift+F11 в конфигураторе с включённой отладкой), чем массовое комментирование. Закомментированный код не должен уходить в рабочую базу — это мусор, который со временем никто не решается удалить, потому что непонятно, нужен ли он ещё.

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

В командной разработке полезно зафиксировать простые правила: язык комментариев (русский), формат заголовков экспортных методов, обязательность маркеров доработок. Это не бюрократия — единый стиль ускоряет чтение чужого кода в разы.

Часть проверок можно автоматизировать. Расширенная проверка конфигурации в конфигураторе (Сервис → Проверка конфигурации) и внешние инструменты анализа кода выявляют неиспользуемые переменные и методы, которые часто остаются после экспериментов с комментированием. Регулярная ревизия модулей на предмет устаревших комментариев — нормальная практика, а не признак педантичности.

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

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

Синтаксис после комментирования

Норма

Модуль сохраняется без ошибок, конфигурация обновляется

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

Ошибки компиляции — вероятно, закомментирована часть выражения или оставлен незакрытый оператор

Читаемость модуля

Норма

Комментарии объясняют причины решений, код без пояснений понятен сам

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

Пояснения дублируют код или противоречат ему

Доработки типового кода

Норма

Каждая вставка обрамлена маркерами начала и конца

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

Изменения смешаны с типовым кодом без пометок

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

Есть ли в 1С многострочные комментарии вида / /?

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

Влияют ли комментарии на производительность?

Практически нет. Комментарии отбрасываются на этапе компиляции модуля и не выполняются. Даже большое количество пояснений не замедляет работу прикладного решения — влияет только объём модуля при чтении и редактировании человеком.

Можно ли комментировать внутри текста запроса?

Да, в тексте запроса комментарии через // поддерживаются, включая пояснения внутри секций ВЫБРАТЬ, ГДЕ и других. Это удобно для документирования сложных соединений и условий, но чрезмерное количество комментариев внутри запроса затрудняет его отладку в консоли запросов.

Как найти все доработки в типовой конфигурации?

Если доработки оформлены маркерами (например, «+++ Доработка»), их находят глобальным поиском по модулям конфигурации (Ctrl+Shift+F). Без маркеров поможет сравнение с типовой конфигурацией поставщика через «Конфигурация → Сравнить, объединить с конфигурацией из файла».

Что делать с закомментированным старым кодом перед сдачей работы?

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

На каком языке писать комментарии — русском или английском?

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