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

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

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

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

Какие правила задаёт стандарт разработки 1С

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

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

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

Как правильно именовать переменные, процедуры и объекты

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

Имена процедур и функций начинаются с глагола в повелительной форме: ПолучитьОстатки, СформироватьОтчет, ПроверитьЗаполнение. Функция, возвращающая булево, должна читаться как утверждение: ЭтоПолноправныйПользователь(), ДокументПроведен().

Избегайте однобуквенных имён вне коротких циклов, транслитерации (Summa, Kolvo) и сокращений, понятных только вам. Имя длиной 25 символов, которое читается без расшифровки, лучше имени из 5 символов, которое нужно комментировать.

Как структурировать модули и процедуры

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

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

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

Комментарии: что писать, а что нет

Комментарий должен объяснять «зачем», а не пересказывать «что делает строка». Комментарий вида // увеличиваем счетчик на 1 бесполезен, а вот пояснение неочевидного бизнес-правила или ссылка на причину обходного решения — ценны. Устаревшие комментарии, противоречащие коду, хуже их отсутствия: при изменении логики обновляйте и пояснения.

Как правильно работать с данными: запросы против обходов

Запрос почти всегда предпочтительнее программного обхода объектов. Конструкция вида «выбрать все документы, в цикле получить объект, проверить условие» загружает в память каждый объект целиком и выполняет множество обращений к базе. Тот же результат одним запросом с отбором выполняется на стороне СУБД и работает на порядки быстрее.

Метод ПолучитьОбъект() нужен только тогда, когда вы собираетесь изменять данные объекта. Для чтения реквизитов используйте запрос или обращение через ссылку с точкой (Ссылка.Номер читает только нужные поля, но в цикле и это порождает отдельные запросы — поэтому в циклах читайте данные пакетно, через запрос).

В тексте запроса всегда используйте параметры (&Параметр) вместо подстановки значений конкатенацией строк. Прямая вставка значений в текст запроса — это и риск ошибок, и потенциальная уязвимость, и проблема с кэшированием планов запросов на СУБД.

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

Как обрабатывать ошибки и писать в журнал регистрации

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

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

Операции, изменяющие несколько связанных объектов, выполняйте в транзакции (НачатьТранзакцию() / ЗафиксироватьТранзакцию() / ОтменитьТранзакцию()). Иначе при сбое посередине часть данных будет записана, а часть — нет, и восстановить согласованность придётся вручную.

Как проверить код перед переносом в рабочую базу

Минимальный набор проверок: синтаксический контроль модуля (выполняется в конфигураторе), проверка конфигурации с включённой проверкой логической целостности, и ручное тестирование сценариев на копии базы с данными, близкими к реальным. На копии с тремя тестовыми документами ошибки производительности и блокировок не проявятся.

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

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

1. 1
   Сделайте копию рабочей базы и разверните её как тестовую
2. 2
   Реализуйте изменение, соблюдая структуру областей и стандарты именования
3. 3
   Выполните синтаксический контроль и проверку конфигурации в конфигураторе
4. 4
   Прогоните основной сценарий и граничные случаи (пустые данные, отмена, повторный запуск)
5. 5
   Проверьте журнал регистрации на отсутствие ошибок после тестов
6. 6
   Сделайте резервную копию рабочей базы и только после этого переносите изменение

Типичные ошибки начинающих разработчиков 1С

Первая группа ошибок — работа с данными: обходы объектов в цикле вместо запросов, модификация данных без транзакций, запись объектов без проверки заполнения. Вторая группа — игнорирование типовых механизмов: собственные велосипеды вместо БСП, прямые запросы к данным, для которых есть программный интерфейс.

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

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