В процессе разработки и поддержки конфигураций 1С в коде часто накапливаются комментарии: закомментированные старые блоки, пометки "доделать", временные отладочные записи. Перед передачей конфигурации на следующий этап или в промышленную эксплуатацию возникает задача привести код в соответствие со стандартами, что подразумевает удаление такого "мусора". Главный вопрос, который при этом возникает: как убедиться, что в процессе чистки были удалены только комментарии и не был затронут рабочий код? Повторное полное тестирование — дорого и долго, поэтому нужна надежная проверка. Рассмотрим несколько способов решения этой задачи.
Это самый простой и наглядный метод, который использует стандартный функционал 1С. Идея заключается в том, чтобы сравнить две версии конфигурации: исходную и ту, что получилась после удаления комментариев.
Разберем процесс по шагам:
Конфигурация → Сохранить конфигурацию в файл... и сохраните ее, например, как original.cf.Конфигурация → Выгрузить конфигурацию в файлы... и укажите пустой каталог.^\s*//.*$. Замените найденные строки на пустые. Будьте внимательны и обязательно сделайте резервную копию каталога с файлами перед массовой заменой.Конфигурация → Загрузить конфигурацию из файлов....Конфигурация → Сравнить, объединить с конфигурацией из файла... и выберите сохраненный ранее файл original.cf.В результате откроется окно сравнения конфигураций. Если вы все сделали правильно, то отличия будут видны только в модулях. Открыв текст модуля для сравнения, вы должны увидеть, что изменения заключаются лишь в удалении строк с комментариями. Если же в окне сравнения вы видите изменения в свойствах объектов, формах или в строках, не являющихся комментариями, — значит, в процессе чистки была допущена ошибка. Этот метод дает отличный визуальный контроль над всеми изменениями.
Это менее очевидный, но, возможно, самый надежный и строгий метод проверки. Его суть в том, чтобы сравнить не исходный код, а скомпилированное представление конфигурации, из которого платформа исключает все комментарии.
Проанализируем этот подход:
Конфигурация → Создать файл поставки и обновления....delivery_before.cf.delivery_after.cf, также убедившись, что исходные тексты модулей не включены.Почему это работает? Когда вы создаете файл поставки без исходных текстов, платформа 1С компилирует все модули в байт-код и сохраняет в файл только его, а также метаданные, макеты, формы и т.д. Комментарии в этом процессе не участвуют и отбрасываются. Если файлы delivery_before.cf и delivery_after.cf абсолютно идентичны, это является стопроцентной гарантией того, что единственными изменениями в конфигурации были комментарии. Никакие изменения в исполняемом коде не остались бы незамеченными.
Этот способ идеально подходит для команд, которые уже ведут разработку с использованием Git. Он позволяет не только проверить изменения, но и задокументировать их.
Посмотрим на алгоритм действий:
git status покажет список измененных файлов, а git diff — детальные изменения в каждом из них. Внимательно просмотрите вывод git diff: вы должны видеть только удаленные строки (они будут подсвечены красным и начинаться с минуса), и все они должны быть комментариями.Дополнительное преимущество: можно настроить Git на использование внешних инструментов сравнения (например, Araxis Merge, Beyond Compare), которые поддерживают синтаксис 1С и могут быть настроены на игнорирование комментариев при сравнении. Это позволяет автоматизировать проверку: если такой инструмент, игнорируя комментарии, не находит различий между двумя версиями, значит, все изменения — косметические.
Мы рассмотрели три эффективных способа контроля изменений при удалении комментариев из конфигурации 1С. Выбор конкретного метода зависит от ваших предпочтений и принятых в команде процессов:
Вне зависимости от выбранного способа, помните о важности резервного копирования перед внесением массовых изменений. А следование стандартам кодирования с самого начала проекта поможет минимизировать количество "мусора" в коде и упростит его поддержку в будущем.