Стандарты оформления текстов, кода и форм в 1С 8.3

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

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

Тексты в первичных документах и реквизитах

Самый массовый случай — оператор или бухгалтер заполняет документ, и от формулировок зависит, как данные уйдут в отчётность и в обмен с контрагентами.

Базовые правила заполнения:

• 💼 Наименование номенклатуры — одно и то же для одной позиции во всех документах. «Бумага А4 500 л.» и «Бумага офисная А4» программа считает разными товарами, и остатки разъедутся.
• 🧾 Назначение платежа в платёжных поручениях — с указанием документа-основания, суммы и ставки НДС («в т. ч. НДС 20% — …» или «Без НДС»). Банк и получатель читают именно эту строку.
• 📅 Даты и номера документов-оснований пишите так, как они стоят в бумажном оригинале, без «причёсывания».
• 🔤 Не смешивайте латиницу и кириллицу в одинаковых по виду символах. С русская и C латинская выглядят одинаково, но для поиска и сопоставления это разные строки.

Если документ ведут несколько человек, договоритесь о едином шаблоне формулировок заранее. Переучивать и чистить справочники потом дороже, чем задать правило на старте.

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

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

Ключевые соглашения по именам:

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

Сравните:

// Так правильно: имя говорит о назначении, стиль единый
Процедура ЗаполнитьТоварыПоСкладу(СкладХранения) Экспорт
    // ...тело процедуры
КонецПроцедуры

// Так плохо: сокращения, транслит, непонятное имя
Процедура ZapolnTov(s) Экспорт
    // ...тело процедуры
КонецПроцедуры

Правила оформления самого текста модуля:

1. Одна инструкция — одна строка, в конце ставится точка с запятой. Несколько операторов через ; в строку не склеивают.
2. Отступы задают вложенность — внутри Если … Тогда, Для … Цикл, Попытка … Исключение тело смещают на один уровень. В типовых используют отступ табуляцией.
3. Перед процедурой или функцией пишут комментарий: что делает, что принимает в параметрах, что возвращает.
4. В управляемом приложении каждую процедуру помечают директивой компиляции — &НаКлиенте, &НаСервере, &НаСервереБезКонтекста. От директивы зависит, где код выполнится и к каким данным получит доступ.

Тексты запросов тоже оформляют единообразно: ключевые слова (ВЫБРАТЬ, ИЗ, ГДЕ) с новой строки, таблицам и полям дают понятные псевдонимы через КАК. Так запрос читается сверху вниз, а не разбирается по словам.

Печатные формы и отчёты: правила вёрстки

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

Что держать в голове при вёрстке макета:

• 📐 Повторяющиеся строки (список товаров, проводок) выносят в отдельную область макета и выводят её в цикле. Фиксированную шапку и подвал — в свои области.
• 🔠 Шрифт и его размер задают на уровне областей, а не каждой ячейки по отдельности — иначе при правке придётся перебирать все ячейки руками.
• 🧮 Числовые ячейки форматируют через параметр формата (число знаков, разделитель), а не вписывают уже готовую строку. Тогда суммы выравниваются по правому краю и считаются итогами.
• 🖨 Проверяйте форму в режиме предварительного просмотра и на реальной ширине листа. То, что влезло на экран, может разъехаться по страницам при печати.

Для отчётов на СКД (система компоновки данных) правило другое: не зашивайте оформление в код, настраивайте его в схеме компоновки — условное оформление, группировки, ресурсы-итоги. Один раз настроенная схема переживёт обновление лучше, чем отчёт, собранный программно «на коленке».

Наименования в справочниках и регистрах

Справочники — фундамент базы. Ошибка в наименовании тиражируется во все документы и отчёты, где элемент участвует.

Правила для элементов справочников:

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

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

Типовая и доработанная конфигурация: где расходятся правила

Разница принципиальная, и от неё зависит, останется ли база на поддержке.

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

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

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

Автоматическая проверка кода и текстов

Не всё нужно вычитывать глазами — часть ошибок ловят встроенные инструменты.

Для кода:

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

Для текстов в документах и справочниках:

• В текстовых полях и редакторе модулей работает проверка правописания — подчёркивает незнакомые слова. Словарь можно дополнять своими терминами.
• Дубли в справочниках ищут обработкой поиска и удаления дублей (в типовых она есть в разделе администрирования/сервиса). Она сопоставляет элементы и склеивает одинаковые, заменяя ссылки в документах.

Частые ошибки оформления