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

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

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

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

Из чего состоит язык 1С и где живёт код

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

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

Структура модуля строго регламентирована: сначала идёт раздел описания переменных, затем процедуры и функции, в конце — раздел основной программы (исполняется при инициализации модуля). Процедуры и функции могут быть экспортными (видимыми из других модулей) или локальными. Это единственный способ организации кода — никаких классов и наследования в привычном ООП-смысле в языке нет.

Как платформа компилирует и выполняет код

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

Ключевая особенность — разделение исполнения между клиентом и сервером. В клиент-серверном режиме код с директивой компиляции «НаСервере» выполняется на сервере 1С:Предприятия, код «НаКлиенте» — на рабочем месте пользователя. Директивы «&НаКлиенте», «&НаСервере», «&НаСервереБезКонтекста» в модуле формы определяют, где будет исполнена каждая процедура. На сервере доступны запросы и запись объектов, на клиенте — элементы интерфейса и диалоги с пользователем.

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

Типы данных и работа со значениями

Язык 1С — язык со слабой динамической типизацией: переменные объявляются без указания типа, а тип определяется присвоенным значением. Базовые примитивы — Число, Строка, Дата, Булево, Неопределено и Null. Значение «Неопределено» означает отсутствие значения вообще, а Null обычно приходит из запросов при соединениях таблиц, где не нашлось соответствия. Смешивание этих двух значений — частый источник трудноуловимых ошибок в условиях.

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

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

// Проверка типов и пустых значений
Если Не ЗначениеЗаполнено(Контрагент) Тогда
Сообщить("Контрагент не указан");
Возврат;
КонецЕсли;

Если ТипЗнч(Параметр) = Тип("СправочникСсылка.Номенклатура") Тогда
Наименование = Параметр.Наименование; // обращение через ссылку
КонецЕсли;

Как код обращается к данным: объекты против запросов

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

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

Типовой сценарий выборки выглядит так: создаётся объект Запрос, задаётся текст, устанавливаются параметры, выполняется метод Выполнить(), результат выгружается в таблицу значений или обходится через Выборку. Параметры запроса всегда передаются через конструкцию «&ИмяПараметра» и метод УстановитьПараметр — конкатенация значений прямо в текст запроса считается плохой практикой и источником ошибок.

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

Контексты выполнения: клиент, сервер, тонкий и толстый клиент

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

На тонком клиенте недоступны, например, прямая работа с файловой системой сервера, COM-объекты, некоторые операции с табличными документами. Если код, написанный и проверенный в толстом клиенте, перестаёт работать у пользователей на тонком клиенте — почти наверняка дело в недоступном в этом режиме методе. Проверяется это через синтакс-помощник: у каждого метода указана доступность по режимам (сервер, толстый клиент, тонкий клиент, веб-клиент).

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

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

Событийная модель: обработчики и подписки

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

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

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

Отладка и проверка работоспособности кода

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

Когда отладчик недоступен (код выполняется в фоновом задании или на сервере без включённой отладки), используют журнал регистрации и вывод диагностических сообщений. Метод Сообщить() подходит для быстрой проверки, но в серверном коде его сообщения увидит только тот сеанс, который выполнял вызов. Для постоянной диагностики надёжнее ЗаписьЖурналаРегистрации с указанием уровня важности.

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

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

Большинство проблем у новичков связано не с синтаксисом, а с непониманием модели исполнения. Код синтаксически верен, но обращается к данным не в том контексте, вызывает сервер из цикла или меняет объект не в том событии. Ниже — ошибки, которые встречаются чаще всего.

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

Частые вопросы о языке 1С