В процессе разработки и поддержки конфигураций 1С программисты часто сталкиваются с ситуацией, когда после рефакторинга или оптимизации кода в модуле формы остаются "осиротевшие" процедуры и функции. Это неэкспортные методы, на которые больше нет ссылок внутри модуля. Оставлять такой «мертвый» код в системе крайне нежелательно: он затрудняет чтение программы, увеличивает объем конфигурации и вызывает справедливые замечания со стороны специалистов по тестированию (QA).
Стандартный Конфигуратор 1С предлагает инструмент полной проверки конфигурации, который умеет находить неиспользуемые процедуры. Однако у этого механизма есть огромный минус — его нельзя запустить точечно для одного конкретного объекта (например, только для той формы, которую вы сейчас правите). Запуск полной проверки всей базы может занять часы, особенно на крупных типовых решениях уровня ERP или Комплексной автоматизации.
В этой статье мы подробно разберем, почему Конфигуратор накладывает такие ограничения, и рассмотрим современные, эффективные альтернативы, которые позволяют мгновенно находить неиспользуемый код в рамках одной формы.
Давайте выясним причину такого поведения платформы. Поиск ссылок на процедуры и функции — это комплексный процесс анализа связей. На первый взгляд кажется, что для неэкспортных методов (у которых нет ключевого слова Экспорт) проверка должна локализоваться строго в пределах одного модуля. Ведь неэкспортную процедуру формы физически невозможно вызвать из другого общего модуля или формы.
Однако алгоритмы проверки Конфигуратора исторически закладывались как глобальные. Платформа анализирует всю конфигурацию целиком для построения полной карты вызовов. Более того, если процедура объявлена как экспортная (даже внутри модуля объекта или формы), она теоретически может вызываться из любого другого места конфигурации. Поэтому частичная проверка с отбором по одному объекту в стандартном Конфигураторе просто не предусмотрена архитектурно.
Но как быть разработчику, которому нужно быстро проверить результаты своей работы "здесь и сейчас"? Рассмотрим доступные и практичные варианты.
Если вы хотите проверять код на лету, наиболее технологичным решением является переход на современную среду разработки 1С:EDT. Она построена на базе Eclipse и выполняет фоновый инкрементальный анализ кода прямо в процессе его написания.
Разберем по шагам, как это работает в 1С:EDT:
module-unused-method (Неиспользуемый метод модуля).Этот подход экономит колоссальное количество времени, так как вы видите свои ошибки еще до момента компиляции и сохранения конфигурации.
Что делать, если вы по-прежнему работаете в классическом Конфигураторе 1С и не планируете переходить на EDT? Для этого сценария отлично подойдет связка Конфигуратора со сторонними инструментами статического анализа кода, такими как BSL Language Server и утилита Phoenix BSL.
Phoenix BSL — это легковесное внешнее приложение с открытым исходным кодом, которое работает "в паре" с Конфигуратором 1С. Проанализируем алгоритм его работы:
Ctrl + I).UnusedLocalMethod моментально укажет вам на все неиспользуемые неэкспортные методы именно в этой форме.Это самый быстрый и удобный способ получить точечную проверку отдельного модуля без необходимости ожидания полной проверки конфигурации.
Если у вас нет возможности установить внешнее программное обеспечение (например, из-за строгих политик безопасности на рабочем месте), можно прибегнуть к "ручному" полуавтоматическому методу анализа выгруженных файлов.
Выполним следующие шаги:
.bsl).ФормаДокумента.bsl) в любом продвинутом текстовом редакторе (Notepad++, VS Code, Sublime Text).(?i)Процедура\s+(\w+)\( или (?i)Функция\s+(\w+)\(.Процедура ИмяМетода()), значит, данная процедура гарантированно не используется в этом модуле и ее можно безопасно удалить.При поиске неиспользуемого кода вы неизбежно столкнетесь с проблемой "ложноположительных" результатов. Это ситуации, когда платформа или анализатор утверждают, что метод не используется, хотя на самом деле он вызывается динамически.
Рассмотрим основные примеры динамических вызовов в 1С:
Выполнить() или Вычислить().ПодключитьОбработчикОжидания("ИмяПроцедуры", ...).Новый ОписаниеОповещения("ИмяПроцедурыЗавершения", ...).УстановитьДействие("ПриИзменении", "ИмяПроцедурыОбработчика").Во всех этих случаях имя процедуры передается в виде текстовой строки. Стандартный парсер Конфигуратора не может сопоставить строковый литерал с реальным объявлением метода, поэтому он выдаст предупреждение: "Не обнаружено ссылок на процедуру".
Чтобы минимизировать количество ложных предупреждений, в профессиональной разработке 1С применяются следующие стандарты:
Согласно стандартам разработки фирмы "1С" (требование АПК), методам, которые предназначены для динамического подключения, следует давать префикс Подключаемый_. Например:
&НаКлиенте
Процедура Подключаемый_ОбработатьВыборРежима()
// Этот метод вызывается динамически через ОписаниеОповещения
КонецПроцедуры
Современные анализаторы кода (включая 1С:EDT и BSL Language Server) обучены игнорировать методы с префиксом Подключаемый_ (или английским аналогом Attachable_) при поиске неиспользуемого кода.
Если вы используете продвинутые системы контроля качества (например, SonarQube или BSL LS), вы можете явно указать анализатору, что данную процедуру не нужно проверять на использование. Для этого используются специальные комментарии-инструкции непосредственно перед объявлением метода:
// BSLLS:UnusedLocalMethod-off
&НаКлиенте
Процедура ИмяПроцедурыДляДинамическогоВызова()
// Код метода
КонецПроцедуры
// BSLLS:UnusedLocalMethod-on
Таким образом, ваш код останется чистым от ложных предупреждений, а автоматические тесты сборки (CI/CD) не будут прерываться из-за ложных срабатываний.
Мы проанализировали проблему поиска неиспользуемого кода для одной конкретной формы в 1С. Несмотря на то, что стандартный Конфигуратор не имеет гибкой настройки отборов для этой операции, вы можете эффективно решать эту задачу с помощью внешних инструментов. Использование 1С:EDT или плагина Phoenix BSL позволяет разработчику мгновенно находить "мертвый" код и поддерживать высокое качество разработки без лишних временных затрат.