Ситуация, когда начинающий разработчик или администратор системы создает новую информационную базу из официального шаблона (например, «1С:Розница»), запускает встроенную функцию «Проверка конфигурации» и видит сотни или даже тысячи ошибок, является классической для экосистемы «1С:Предприятие». На первый взгляд это кажется критической проблемой: как может официальный продукт от вендора содержать столько дефектов? Однако в реальности большинство этих сообщений не являются признаком неработоспособности системы.
В данной статье мы подробно разберем, почему встроенный механизм проверки выдает такие результаты, как отличить реальные проблемы от «шума» и как правильно настроить инструменты контроля качества кода в своей работе.
Для начала проанализируем ситуацию с точки зрения внутренней кухни разработки компании «1С». Важно понимать, что инструменты, которыми пользуемся мы в Конфигураторе, и инструменты, которые применяют разработчики типовых решений, различаются по своим задачам и строгости.
АПК (Автоматизированная проверка конфигураций). Это мощная внешняя система, которая проверяет код на соответствие сотням стандартов. Многие предупреждения, которые встроенный в Конфигуратор чеккер помечает как ошибки, в АПК могут быть внесены в список исключений. Разработчики сознательно идут на определенные допущения ради универсальности кода.БСП. Это гигантский набор универсальных механизмов. Чтобы оставаться универсальной, библиотека содержит избыточный код, который может быть не задействован в конкретной конфигурации «Розница», что вызывает сообщения о неиспользуемых переменных или пустых ссылках.Ошибки или Предупреждения, рекомендуя использовать более современные методы.#Если НаКлиенте Тогда. Если при проверке включить все галочки одновременно, система может запутаться в контекстах и выдать ложную ошибку о доступности метода.В обсуждении часто упоминается статус «1С:Совместимо». Это набор жестких требований к оформлению кода и структуре метаданных. Типовые конфигурации (такие как «Розница») де-факто являются эталоном, но технически они настолько сложны и объемны, что прогнать их через встроенную проверку с включенным флажком «Проверять на соответствие требованиям 1С:Совместимо» без единой ошибки практически невозможно. Этот режим проверяет даже такие мелочи, как длина заголовков кнопок или наличие комментариев к экспортным методам в модулях. Для повседневной работы программиста этот режим, как правило, является избыточным.
Чтобы не тонуть в море сообщений о «неправильных» комментариях в типовых модулях и видеть только то, что действительно важно для работоспособности программы, выполним правильную настройку окна «Проверка конфигурации». Рассмотрим пошагово, какие флажки стоит оставить, а какие — снять.
Шаг 1: Настройка синтаксического контроля. Это самый важный этап. Синтаксические ошибки — это те ошибки, из-за которых программа просто «упадет» у пользователя. Однако проверять их нужно раздельно для разных контекстов. Рекомендуется запускать проверку несколько раз или внимательно смотреть на группировку:
Тонкий клиент — проверка кода, который исполняется на стороне пользователя.Сервер — проверка серверных процедур и функций.Внешнее соединение — критично, если база будет обмениваться данными с другими системами.Шаг 2: Выбор объектов для проверки. Если вы только что создали базу из шаблона и не вносили изменений, проверять всю конфигурацию целиком нет практического смысла. Но если вы начали доработку, выберите в дереве метаданных только свои объекты или расширения. Это позволит сфокусироваться на собственном коде.
Шаг 3: Отключение лишних опций. При работе с типовыми решениями («Розница», «УТ», «БП») мы рекомендуем снимать следующие флажки:
Проверка логической целостности конфигурации — часто выдает сотни предупреждений о макетах и правах доступа, которые не влияют на работу.Поиск неиспользуемых процедур и функций — для конфигураций на БСП этот список будет бесконечным.Проверка существования назначенных обработчиков — в формах типовых решений иногда используются динамические механизмы назначения событий, которые проверка не видит.Для профессионального разработчика существует методика «нулевого замера». Проанализируем ситуацию: вы развернули чистую «Розницу». Прежде чем написать первую строчку своего кода, запустите стандартную проверку синтаксиса. Предположим, система выдала 140 предупреждений. Запомните это число или сохраните результат в текстовый файл.
Это и есть ваш «Золотой эталон» или «точка нуля». Все те 140 ошибок — это «наследство» от разработчиков типового решения, которое не мешает работе программы. Ваша задача как специалиста — следить, чтобы после ваших правок это число не увеличилось. Если после добавления новой функции количество ошибок стало 141 — значит, вы допустили реальную ошибку в своем коде, которую нужно исправить.
Рассмотрим на примере, почему возникают «ложные» срабатывания в модулях. Возьмем типичный фрагмент кода, использующий инструкции препроцессора:
#Если Сервер Тогда
Процедура ВыполнитьДействиеНаСервере()
// Код для сервера
КонецПроцедуры
#КонецЕсли
#Если ТонкийКлиент Тогда
Процедура НажатьКнопку(Команда)
ВыполнитьДействиеНаСервере(); // Здесь может возникнуть ошибка проверки
КонецПроцедуры
#КонецЕсли
В данном примере, если в настройках проверки включен только Тонкий клиент, система может выдать ошибку Процедура или функция с указанным именем не определена, так как она «не видит» серверный контекст. Именно поэтому важно понимать, в каких режимах работает ваш код и какие флажки установлены в окне проверки.
Также стоит обратить внимание на работу с объектами метаданных через ОбщегоНазначения. В «Рознице» часто встречаются конструкции вида:
ЗначениеПараметра = ОбщегоНазначения.ЗначениеРеквизитаОбъекта(СсылкаНаОбъект, "ИмяРеквизита");
Встроенный механизм проверки не может проверить корректность строки "ИмяРеквизита", так как это просто текстовый параметр. Однако АПК, используемый в «1С», может это проверить. Это еще раз подтверждает, что встроенная проверка в Конфигураторе — лишь базовый инструмент, и не стоит доверять ему на 100% при анализе сложных типовых решений.
Если вы открыли «Розницу» и увидели сообщения об ошибках при проверке — не паникуйте. Это нормально. Типовые конфигурации — это живые, развивающиеся системы с огромным багажом кода для обеспечения универсальности. Чтобы эффективно работать, придерживайтесь следующих правил:
Помните, что главным критерием работоспособности системы является отсутствие реальных сбоев (Runtime errors) в процессе эксплуатации пользователями, а не «чистота» логов встроенного детектора ошибок.