При работе в многопользовательском режиме, особенно с использованием Хранилища конфигурации 1С, разработчики часто сталкиваются с неприятной ситуацией: при сравнении и объединении модулей стандартный механизм конфигуратора «разрывает» процедуры. Последняя строка КонецПроцедуры может внезапно оказаться в другом блоке или пометиться как измененная, хотя логически код не менялся. В этой статье мы подробно рассмотрим, как правильно настроить шаблоны комментариев (автотекст) и как оформлять свои правки, чтобы минимизировать подобные конфликты. В некоторых случаях решить проблему помогает объединение модулей в разрезе методов с помощью KDiff3, которое теперь доступно и для обычного конфигуратора.
Прежде всего, проанализируем ситуацию, почему стандартный конфигуратор 1С ведет себя подобным образом. В основе механизма сравнения текстов в 1С лежит алгоритм LCS (Longest Common Subsequence) — поиск наибольшей общей подпоследовательности. Этот алгоритм ориентируется на строки текста. Когда мы добавляем комментарий вплотную к синтаксическим конструкциям языка (например, сразу после КонецПроцедуры), алгоритм может ошибочно посчитать, что эта строка теперь неразрывно связана с вашим комментарием, а не с телом функции.
Выясним основную причину «отрыва» строк: чаще всего это происходит из-за отсутствия пустых строк между вашим блоком комментариев и ключевыми словами языка. Если ваш шаблон настроен так, что он «прилипает» к коду, риск получить «кашу» при обновлении конфигурации или захвате объекта в хранилище возрастает в разы.
Рассмотрим, как создать шаблон, который будет не только информативным, но и технически правильным. Для этого в конфигураторе перейдем в меню Сервис — Шаблоны текста. Вы можете создать новый файл шаблонов или внедрить в работу команды готовые шаблоны для применения стандартов и методик разработки.
Посмотрим на пример лаконичного и удобного шаблона, который применяет продвинутые техники настройки файлов .t9c для автоматизации ввода даты и номера задачи. Использование символов { } или + - внутри комментариев позволяет визуально выделять блоки даже в сложных модулях.
Пример настройки шаблона (автотекста):
//{-- Иванов.Б <?"Дата", Дата, "ДФ=dd.MM.yyyy"> #<?"Номер задачи">
<?>
//--} Иванов.Б
В этом примере мы используем конструкцию <?>, которая указывает конфигуратору, где оставить курсор после вставки шаблона. Параметры в угловых скобках с вопросительным знаком <?"..."> вызовут диалоговое окно для ввода данных, что гарантирует единообразие формата даты у всех разработчиков команды.
Теперь проанализируем ситуацию: куда именно вставлять комментарий при изменении существующего кода? Существует два основных подхода, и выбор зависит от того, что именно вы меняете. Чтобы упростить этот процесс и привести весь код к единому виду, можно использовать инструмент Code formatter 1C для автоматического редактирования модулей.
Вариант 1: Изменение логики внутри существующей процедуры
Если мы правим алгоритм внутри функции, крайне рекомендуется ставить комментарии строго внутри тела процедуры, после заголовка и до закрывающего слова. Рассмотрим это на примере:
Процедура УправлениеВидимостью()
// {++ Иванов.Б 11.04.2025 #12345
// Новый код или измененная логика
Элементы.ГруппаСкидок.Видимость = Истина;
// }++ Иванов.Б
КонецПроцедуры
Такой подход гарантирует, что при сравнении модулей заголовок Процедура и завершение КонецПроцедуры останутся на своих местах, так как они не затронуты вашими тегами.
Вариант 2: Добавление новых процедур и функций
Когда мы добавляем новый метод целиком, ситуация меняется. Здесь важно отделить новый блок кода от существующего «соседнего» кода. Разберем по шагам, как это сделать правильно:
// Параметры:).Посмотрим на пример оформления нового метода:
// {++ Иванов.Б 11.04.2025 #12345
// Функция определяет, является ли объект документом.
//
Функция ЭтоДокумент(ОбъектМетаданных) Экспорт
Возврат Метаданные.Документы.Содержит(ОбъектМетаданных);
КонецФункции
// }++ Иванов.Б
Многие опытные разработчики предпочитают ставить закрывающий тег прямо в строке с КонецФункции. Это допустимо, если ваша команда договорилась о таком стандарте, но вариант с пустой строкой более надежен для автоматических инструментов сравнения.
Проанализируем современные тренды разработки на платформе 1С. В крупных проектах все чаще отказываются от указания фамилий в комментариях. Почему? Потому что информация о том, кто и когда изменил строку, идеально хранится в системах контроля версий (Git). Если вы планируете переход на новые технологии, вам помогут приемы быстрой работы в EDT и Git, где проблема «разрыва строк» практически исчезает, так как EDT оперирует структурой метаданных.
Однако, если вы продолжаете работать в классическом конфигураторе, мы рекомендуем придерживаться следующих правил:
//НАЧАЛО БЛОКА ИЗМЕНЕНИЙ ТАКОГО-ТО РАЗРАБОТЧИКА используйте краткие маркеры, например //+ и //-. Это уменьшает визуальный шум и объем файла модуля..t9c для всех разработчиков в отделе. Это исключит ситуацию, когда один пишет «Иванов», а другой «Иванов Б.».Для исправления проблемы, описанной автором темы, необходимо пересмотреть структуру шаблона и добавить в него принудительные переносы строк. Рассмотрим исправленный вариант шаблона для вставки «снаружи» процедур:
// {++ <?"Автор"> <?"Дата", Дата, "ДФ=dd.MM.yyyy"> #<?"Задача">
<?>
// }-- <?"Автор">
При использовании такого шаблона всегда убеждайтесь, что между // }-- и следующим за ним кодом (или предыдущим) есть пустая строка. Это «золотое правило» разработки в 1С позволит вам забыть о проблемах со смещением строк при сравнении конфигураций и сделает ваш код профессиональным и читаемым.