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

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

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

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

Какие стандарты разработки 1С стоит принять за основу

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

Минимальный набор, который стоит внедрить в первую очередь: единый язык кодирования (в типовых — русский, с английскими синонимами в общих модулях библиотек), отступ табуляцией, осмысленные имена без транслита вида SpisTovar, комментарии только там, где неочевидна логика, а не сам синтаксис. Комментарий «увеличиваем сумму на 1» у строки Сумма = Сумма + 1; — мусор, а пояснение, почему выбран именно такой алгоритм расчёта, — полезен.

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

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

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

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

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

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

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

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

Главное правило производительности в 1С: данные обрабатываются запросом на сервере СУБД, а не перебором в цикле. Конструкция «запрос по справочнику, выборка, внутри цикла ещё один запрос» — классическая ошибка, из-за которой отчёт, работавший секунды на тестовой базе, на рабочей выполняется минутами. Соединяйте таблицы в одном запросе, используйте временные таблицы и пакетные запросы.

Ещё несколько обязательных правил: параметры передавайте через Запрос.УстановитьПараметр(), а не конкатенацией строки запроса; виртуальные таблицы регистров (Остатки, Обороты) сразу ограничивайте отбором по периоду и измерениям; не используйте СОЕДИНЕНИЕ с табличными частями без необходимости. Для проверки результата удобно сначала отладить запрос в консоли запросов на копии базы и только потом переносить в код.

Как обрабатывать ошибки и исключения

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

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

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

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

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

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

Как писать код, который не придётся переписывать

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

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

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

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

Читаемость кода

Норма

Коллега понимает назначение процедуры по имени и читает тело без пояснений автора

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

Нужно объяснять устно, что делает каждый блок

Производительность

Норма

Типовая операция на рабочих объёмах выполняется за приемлемое время без роста при увеличении данных

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

Время выполнения заметно растёт с ростом базы, в замере видны запросы в цикле

Устойчивость к данным

Норма

Код корректно отрабатывает пустые и неожиданные значения, ошибки фиксируются в журнале

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

На нестандартных данных возникают необработанные исключения или тихие неверные результаты

Обновляемость

Норма

Доработки вынесены в расширение, обновление типовой конфигурации проходит штатно

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

Изменены типовые модули, обновление требует ручной сверки

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

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

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

Обязательно ли использовать расширения вместо доработки конфигурации?

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

Чем опасен запрос в цикле и как его заменить?

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

Нужно ли объявлять переменные явно в 1С?

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

Как понять, что код готов к переносу в рабочую базу?

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