Комментарии. Какие и зачем?

17.11.15

Разработка - Рефакторинг и качество кода

Рассмотрим комментарии, которые используют программисты 1С при доработке и сопровождении конфигураций.
И попробуем их улучшить.

Все написанное ниже является моим мнением, и я буду рад критике и обсуждениям.

1. Обычный комментарий

// infostart Начало 15.11.2015
НоваяПеременная = СтараяПеременная + 1;
// infostart Окончание 15.11.2015

Узнаете? Обычный комментарий обычного программиста 1С. 

Давайте представим, что этот комментарий Вы видите через два года или его вообще писали не Вы.
Что мы из него можем понять? Кто-то что-то изменил. Разве этого достаточно?

Как можно улучшить?

Когда мы что-то изменяем в типовой конфигурации, то мы изменяем это для какой-то конкретной цели. Эту цель и следует указывать в комментариях. Такой комментарий позволит вспомнить, зачем и почему было сделано такое изменение. Но если с целью всё плохо, напишите, для кого Вы делали это изменение. В дальнейшем цель можно будет уточнить у этого человека.

2. Было/стало 

А = А + В;
// infostart Начало 
// Было B = A - 5:
// Стало
В = А - 4;

Такие комментарии используются для того, чтобы восстановить типовой алгоритм. Но по факту мы ухудшаем наглядность кода. А при сравнении и объединении конфигураций отображаются три строки, вместо одной.

Как можно улучшить?

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

А = А + В;
В = А - 4; // infostart Было B = A - 5:

3. Идентификация новых процедур

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

 

Вроде всё в порядке, и так нам легче ориентироваться в модуле. Но есть один неприятный момент - при сравнении и объединении будут отображаться лишние изменения в разделе основной программы:

Это доставляет определенные неудобства, если измененных объектов в конфигурации много.

Как можно улучшить?

Для добавления новых процедур лучше использовать другие способы идентификации, например, префикс перед названием процедуры:

Процедура Infostart_НоваяПроцедура(Параметр1)

    Параметр1 = Параметр1 + 1

КонецПроцедуры

Напоследок еще один способ использования комментариев

В своих проектах наша команда использовала комментарии, как уникальные идентификаторы для изменения конфигураций. Эти идентификаторы служат связью технического задания с кодом конфигурации.

Работает это следующим образом:

  1. Задаче присваивается уникальный идентификатор (например, ТЗ01_НДС).
  2. Во всех местах, где вносятся изменения, в комментариях указывается данный идентификатор.

Это позволяет легко и быстро найти и изменить доработанные механизмы и ничего не забыть при этом. 

Работает это следующим образом:

  1. Открываем ТЗ и находим уникальный идентификатор.
  2. Глобальным поиском находим все места, где были изменения.
  3. Дорабатываем.

Можно использовать идентификаторы и наоборот. Например, изучаете код, но не можете понять, для чего было сделано изменение. По уникальному идентификатору ищем в ТЗ необходимую информацию.


На этом все. Буду рад, если Вы поделитесь своими способами использования комментариев.

Вступайте в нашу телеграмм-группу Инфостарт

Комментарии Разработка Красивый код Пишем правильно

Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».

  • 0% комиссии — оплата напрямую исполнителю;
  • Исполнители любого масштаба — от отдельных специалистов до команд под проект;
  • Прямой обмен контактами между заказчиком и исполнителем;
  • Безопасная сделка — при необходимости;
  • Рейтинги, кейсы и прозрачная система откликов.

См. также

Инструментарий разработчика Рефакторинг и качество кода Программист 1С 8.3 1С 8.5 1С:Документооборот 1С:Бухгалтерия 3.0 1С:Управление нашей фирмой 3.0 Россия Абонемент ($m)

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

2 стартмани

08.07.2026    400    4    NikolayMaerov    0    

4

Рефакторинг и качество кода Обновление 1С Программист 1С:Предприятие 8 1С:ERP Управление предприятием 2 Бесплатно (free)

На проекте сложного обновления 1С:ERP 2.4.14.181 до версии 2.5.22.106 нам было нужно уложить обновление в технологическое окно 48 часов (выходные). Исходный замер, с учетом промежуточных релизов 2.5.8.443, 2.5.12.270, 2.5.17.234, 2.5.22.106, показал требуемое время в 659 часов…

07.07.2026    2354    1c-izh    19    

19

Рефакторинг и качество кода Обновление 1С Программист 1С 8.3 Бесплатно (free)

Обновление ролей в расширении 1С отличается от аналогичного процесса в основной конфигурации. Ситуация осложняется, когда доработки вносятся не в «обычное», а в поставляемое расширение.

26.06.2026    825    1c-izh    3    

5

Рефакторинг и качество кода Программист Россия Бесплатно (free)

Code review в 1С часто превращается в спор вкусов: “мне не нравится”, “переделай”, “так не делают”. В статье разбираю другой подход: проверять не разработчика, а риск для системы. Показываю, как формулировать замечания без токсичности, где заканчивается личное предпочтение и начинается реальная проблема, почему ревью должно развивать разработчика, а не только исправлять код

24.06.2026    760    NikolayMaerov    4    

6

Нейросети Рефакторинг и качество кода Программист Бесплатно (free)

Показываем, как встроить ИИ-помощника в code review 1С без Git, SonarQube и EDT – только с Конфигуратором, RAG-контекстом и набором MCP-инструментов. Разбираем архитектуру решения на Open Web UI и OpenRouter, методику сравнения моделей по Precision, Recall, BonusRate и PenaltyRate, а также объясняем, почему контекст влияет на качество ревью сильнее, чем выбор самой модели. На реальных примерах показываем, какие ошибки ИИ находит хорошо, где все еще нужен архитектор и почему на старте пилота время ревью может не сократиться, а вырасти. В финале делимся метриками внедрения и выводами для команд, которые хотят повторить такой подход у себя.

17.06.2026    1024    NVyunova    1    

3

Нейросети Рефакторинг и качество кода Программист Бесплатно (free)

Кажется, что code-review с помощью искусственного интеллекта устроено просто: достаточно отправить код в LLM, задать промт и получить список замечаний. На практике такой подход быстро упирается в недетерминированность результата, неверную оценку критичности ошибок в 1С-коде и рекомендации, которые сложно отличить от полезных замечаний. Описываем гибридный подход к автокод-ревью: статический анализатор работает вместе с LLM, а база знаний из стандартов 1С превращается в набор машиночитаемых норм. Такая архитектура помогает снизить количество галлюцинаций, точнее определять критичность нарушений и постепенно развивать качество ревью через итеративное пополнение правил.

09.06.2026    1963    Repich    5    

9

Рефакторинг и качество кода Программист Бесплатно (free)

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

04.06.2026    1050    IgorVasilyev    29    

5

Инструментарий разработчика Рефакторинг и качество кода Программист 1С 8.3 Абонемент ($m)

MetaVision for 1C PRO — профессиональная версия статического анализатора и визуализатора кода. Загружает выгрузки конфигураций, расширения и внешние файлы, за секунды строит графы функций, находит уязвимости безопасности и подсвечивает проблемы производительности. В арсенале: визуализация логики в виде графов условий, циклов, транзакций и вызовов, статический аудит безопасности с поиском RCE, SSRF, COM-инъекций и паролей в коде, выявление запросов в циклах и вложенных блокировок, полнотекстовый поиск по всем модулям, встроенный редактор с конвертером запросов и автоформатированием, а также честная статистика по объектам и функциям. Главное новшество PRO — до пяти конфигураций одновременно с мгновенным переключением, наложение до пяти расширений как в конфигураторе, анализ внешних файлов в единой связке с основной конфигурацией и пять тем оформления. Инструмент для тех, кто ведёт несколько проектов параллельно и хочет видеть полную картину в одном окне — быстро, наглядно и безопасно.

7 стартмани

19.05.2026    3348    35    KHoroshulinAV    7    

13
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. antonov_i 320 17.11.15 01:46 Сейчас в теме
Если говорить о комментариях для описания функций, то я уже давно пришел в стилю jsDoc. Например

//**
//* Это супер функция, которая делает, что-то
//* важное.
//*
//* @param {Число} Параметр1
//* @param {СправочникСсылка.Контрагенты} Контрагент
//* @return {Массив.<СправочникСсылка.Номенклатура>}
Функция МояСуперФункция (Параметр1, Контрагент)
//TODO написать код функции
КонецФункции
Показать


Плюсы от такого стиля очевидны: компактность, стандартизация. Последний пункт позволяет без проблем задокументировать код и создать какой-нибудь симпатичный документ. Что касается комментариев к отдельным строкам кода, то тут лично у меня прижился уже классический вариант:

//АИВ 01.01.01 \ Комментарий / 


Или многострочный вариант

//АИВ 01.01.01 \
//Комментарий
//АИВ 01.01.01 /
2. vcv 89 17.11.15 08:24 Сейчас в теме
Многое зависит от назначения комментария. Комментарии в стиле jsDoc, помянутые в (1) полезны. Позволяют автоматически формировать документацию и понимать смысл параметров, не анализируя код.
А вот комментарии в виде
//АИВ 01.01.01 \
//Комментарий
//АИВ 01.01.01 /
или
Во всех местах, где вносятся изменения, в комментариях указывается данный идентификатор.
сильно спорны. Главная их проблема в том, что их актуальность нужно поддерживать. Вот, представьте, что для техзадания ТЗ01_НДС вы изменили строки 100-110 и отметили их комментарием. Потом, через годик, по техзаданию Т515_НДС вы в этом же модуле изменяли строки 80-120. Куда вы денете комментарий ТЗ01_НДС и какова будет его актуальность?
Для часто дописываемых проектов лучше использовать какой-нибудь git. Что бы всё было чётко: есть коммит, есть назначение коммита, есть внесенные им изменения.
ivangrant; o.nikolaev; +2 Ответить
5. mrXoxot 3212 17.11.15 09:19 Сейчас в теме
(2) vcv,

Главная их проблема в том, что их актуальность нужно поддерживать.

Это действительно так. Но вообще и актуальность кода лучше поддерживать.

Для часто дописываемых проектов лучше использовать какой-нибудь git. Что бы всё было чётко: есть коммит, есть назначение коммита, есть внесенные им изменения.

Ну для этого ждем EDT, кажется там уже это будет поддерживаться в полном объеме.
12. antonov_i 320 18.11.15 01:39 Сейчас в теме
(2) vcv,

Тут еще все зависит от проекта. Мне не очень нравится хранить историю комментариев, ибо потом в коде трудно ориентироваться. Для детального описания изменений есть трекер. В принципе, отследить что менялось можно истории задач. Ну а если прям нужны детали до "строчки", то тут без GIT не обойтись.
4. mrXoxot 3212 17.11.15 09:16 Сейчас в теме
(1) dalgaso2010,

Да, с описание параметров действительно получаются отличные комментарии. К тому же текущая версия платформы позволяет такие комментарии использовать в синтаксис-помощнике. Например как на приложенном скриншоте.
Прикрепленные файлы:
3. kraynev-navi 700 17.11.15 09:04 Сейчас в теме
Вот, представьте, что для техзадания ТЗ01_НДС вы изменили строки 100-110 и отметили их комментарием. Потом, через годик, по техзаданию Т515_НДС вы в этом же модуле изменяли строки 80-120. Куда вы денете комментарий ТЗ01_НДС и какова будет его актуальность?

А что мешает переделать строки 100-110 в рамках проекта по изменению 80-120?
Т.е.
//Т515_НДС (
//Комментарий 
..
//ТЗ01_НДС (
//Комментарий поясняющий изменения в связи с новой заявкой Т515_НДС 
// ) ТЗ01_НДС
...
// ) Т515_НДС 
Показать
8. vcv 89 17.11.15 11:05 Сейчас в теме
(3) kraynev-navi,
А что мешает переделать строки 100-110 в рамках проекта по изменению 80-120?

Да, переделаете. Но что делать с комментарием? На сколько этот комментарий будет соответствовать результирующему коду? Особенно если его (этот комментарий и прошлое изменение) писали не вы.
Обычное же дело. Сначала изменили строки 100-110. Потом, по другому заданию, 90-110. Потом 80-100. Потом переписалось все с 50 по 150.
Куда и как девать старые комментарии?
Это действительно так. Но вообще и актуальность кода лучше поддерживать.

Но ведь гораздо проще и экономически эффективней просто писать хороший читабельный код, чем писать хороший код, к нему хорошие комментарии и поддерживать соответствие кода и комментариев.
9. mrXoxot 3212 17.11.15 12:12 Сейчас в теме
(8) vcv,

Сначала изменили строки 100-110. Потом, по другому заданию, 90-110. Потом 80-100. Потом переписалось все с 50 по 150

Не исключаю, что такая ситуация может быть, но мы с этим как то не сталкивались. В случае если рядом есть изменения по другим задачам, то они просто указываются рядом.

Если потребовалось переписать все с 50 по 100, тогда это уже будет новая задача, которая исключает предыдущие.

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

Абсолютно полностью поддерживаю! Лучше писать хороший читабельный код, это факт. Но, к сожалению, не всегда это удается и тогда на выручку приходят комментарии.
6. JesteR 156 17.11.15 09:50 Сейчас в теме
В свои комментарии добавляю номер задачи. Задач бывает несколько и довольно долгих по времени.
Поэтому использую шаблон 1С, пример:
//{MyLogin (<?"НомерЗадачи", ВыборВарианта, 
	"Резервы", "105", 
	"Доработкая для буха", "102", 
	"Без номера", "">) <?"", ДатаВремя, "ДФ=yyyy.MM.dd">  
<?>  
//MyLogin (<?"НомерЗадачи", ВыборВарианта>) <?"", ДатаВремя, "ДФ=yyyy.MM.dd"> }
Sintson; Y_U_S; Bassgood; АлексейП; Михаська; mrXoxot; +6 Ответить
7. mrXoxot 3212 17.11.15 11:01 Сейчас в теме
(6) JesteR,
А вот это действительно здорово. Спасибо!
10. klinval 346 17.11.15 17:55 Сейчас в теме
(0) В 3-м пункте вы написали:
Процедура Infostart_НоваяПроцедура(Параметр1)

    Параметр1 = Параметр1 + 1

КонецПроцедуры

А вы эту процедуру поместите в конце модуля? Просто тогда раздел основной программы будет различаться из-за #КонецОбласти....
Есть второй вариант: поместить перед разделом основной программы, но тогда будет так что, например, в область "Печать" попадёт какая-нибудь процедура "ПриИзменениЧегоЛибо".
11. vcv 89 17.11.15 19:33 Сейчас в теме
(10) klinval,
Вот кстати, не касательно пункта 3, а касательно приведенной процедуры.
Процедура Infostart_НоваяПроцедура(Параметр1)

    Параметр1 = Параметр1 + 1

КонецПроцедуры

Чем подобных процедур меньше, тем лучше. Неявная модификация переданного в процедуру параметра - зло.
13. o.nikolaev 217 18.11.15 09:02 Сейчас в теме
>> Процедура Infostart_НоваяПроцедура(Параметр1)
>> Параметр1 = Параметр1 + 1
>> КонецПроцедуры

Не использую такой подход. Только хранилище и внешние СКВ (системы контроля версий).

Автор, без обид, прочитайте волшебную книжку "Совершенный код" Стива Макконнелла, там все написано по этой теме. При доработках типовых включаю хранилище и все доработки делаю через него. В комментарии к версии указываю и номер задачи и описание изменений. В том случае, если работа с клиентом заканчивается, передаю ему и хранилище и базу задач. В базе задач хранится все - кто, что, когда, зачем, файлы и т.п. (последователю понадобится и пригодится).

Для внешних обработок использую Tortosie.
Designer1C; +1 Ответить
19. mrXoxot 3212 18.11.15 12:40 Сейчас в теме
(13) o.nikolaev,

Расскажите, пожалуйста, подробнее про Tortosie - а то гугл выдает, что это тяжелый штурмовой танк.

(16) V.Nikonov,

2. Задокументировать отличия от типового решения. (Такие комментарии должны облегчать обновления типового продукта. В т.ч. содержат описания кода, который необходимо сохранить при обновлениях)

Здесь не совсем согласен. Отличия от типового решения прекрасно видны при сравнении и объединении, гораздо важнее объяснить почему здесь не устраивает типовая логика.

(18) vcv,
Git и прочее рулит, но прилично написанные комментарии в коде ценны, когда ты пробегом у клиента несколько раз в году. Всему своё место. Для фикси требуется толковая система типа git, на аутсорсинге хорошо бы толковый комментарий оставить себе или другому аутсорсеру


Да, если это изменения у обычного клиента с мелкой доработкой, то использовать Git для этой доработки, кажется, излишним.
21. o.nikolaev 217 18.11.15 13:17 Сейчас в теме
14. orefkov 1158 18.11.15 09:28 Сейчас в теме
Имхо, все эти комментарии о вносимых изменениях - от безысходности и отсутствия нормальной системы управления версиями.
Началось ещё с семёрки, да так и прижилось.
На мой взгляд, комментарии должны всегда отображать текущее состояние и пояснять только текущий функционал.
Кому нужна история - пусть копаются в летописях. Так вот в 1С - нет удобной системы их писания и копания, поэтому летописи перекочёвывают в код, превращая его в "преданья старины глубокой". На кой, извините ляд, мне знать, что три года назад тут был Вася и убрал то, что пять лет назад вписал Петя?
tormozit; json; Designer1C; Dem1urg; sbcode; ivanov660; chernyakai; shootnik; CratosX; mrXoxot; o.nikolaev; FrLenok; V.Nikonov; artbear; Quasar; klinval; +16 Ответить
18. vcv 89 18.11.15 12:16 Сейчас в теме
(14) orefkov,
На кой, извините ляд, мне знать, что три года назад тут был Вася и убрал то, что пять лет назад вписал Петя?

В таком виде не нужно. А вот понять, зачем кто-то или ты сам вставил или закомментарил определенные строки, может быть полезно. Потому что бывают тонкости, о которых сразу не сообразишь, которые вылазят раз в месяц на определенном документе...

(15) artbear, Git и прочее рулит, но прилично написанные комментарии в коде ценны, когда ты пробегом у клиента несколько раз в году. Всему своё место. Для фикси требуется толковая система типа git, на аутсорсинге хорошо бы толковый комментарий оставить себе или другому аутсорсеру.
22. o.nikolaev 217 18.11.15 13:20 Сейчас в теме
(18) vcv,
Потому что бывают тонкости, о которых сразу не сообразишь, которые вылазят раз в месяц на определенном документе...

Это значит что код написано неясно. Соблазн подобного рода, за счет комментариев попытаться сгладить кривизну решения, велик, и грешат им, чоуш. Но это неправильно. Опять же, повторюсь, у Макконнела про все это написано более подробно и убедительно.
v.yaunzhekars@gmail.com; +1 Ответить
27. vcv 89 18.11.15 17:37 Сейчас в теме
(22) o.nikolaev,
Это значит что код написано неясно. Соблазн подобного рода, за счет комментариев попытаться сгладить кривизну решения, велик, и грешат им, чоуш. Но это неправильно.

Код, это всё же некая модель, абстракция. Полное понимание этой абстракции не даёт понимания, на сколько она соответствует требованиям и по какой причине в данном месте применена именно данная абстракция. Так что комментарии нужны. А уж где они хранятся, это вопрос второй. Хоть в описании коммита, хоть в хранилище, хоть в коде (внутри функции или перед её определением) - это уже техническая организация хранения описания абстракции.
15. artbear 1589 18.11.15 10:24 Сейчас в теме
(0) и другие: "Авторские" комментарии - зло, как уже написали несколько человек.
Представляете, какой у вас будет код через несколько лет? немного реального кода и куча комментариев "тогда-то здесь отметился Вася по такой-то нужде" :)
Git (blame), системы код-ревью рулят.

Используйте фоновую выгрузку из 1С в Git, например, наш бесплатный открытый проект gitsync
и уже в Гите смотрите историю, кто и что, когда и почему менял.
GnatyukMV; +1 Ответить
16. V.Nikonov 126 18.11.15 10:57 Сейчас в теме
По моему у комментариев есть несколько целевых задач:
1. Объяснить ход выполнения функционала, уточнить логику решения и т.п. (Это самое важное! Без этого затруднена отладка и модификация программы.)
2. Задокументировать отличия от типового решения. (Такие комментарии должны облегчать обновления типового продукта. В т.ч. содержат описания кода, который необходимо сохранить при обновлениях)
3. Протоколировать решение дополнительных прикладных задач. (Подразумевается наличие документации в виде проработанного ТЗ на доработку)

Для каждой из задач формат комментариев выглядит по разному. Вероятно, что в процессе должны писаться комментарии всех необходимых видов.
Кроме того, в ходе написания актуальных комментариев, желательно подчищать комментарии оставленные "предками". Особенно, если предыдущие доработки теряют актуальность. Например, хранить сведения, что некий коэффициент в 2010 году был 1.5, в 2012 стал 1.6, а с 2015 года равен 1.65 - вероятно не следует. Комментарий должен служить сегодняшнему и завтрашнему дню!
RustIG; tormozit; Designer1C; fomix; CratosX; mrXoxot; +6 Ответить
17. NazarovV 87 18.11.15 12:02 Сейчас в теме
Мы вот так комментируем)
//Заявка №000002911 Назаров В.Г. 18 ноября 2015 г. {{

//Заявка №000002911 Назаров В.Г. 18 ноября 2015 г. }}

Формируется автоматически в буфер из базы заявок...

Если мы комментируем чужой код или типовой есть несколько вариантов:
Если код типовой - комментируем всегда;
Если код не типовой, в нем ошибка или понимаем что логика устарела - удаляем и пишем свое.
Если код не типовой и возможно, что в будущем возможно возвращение к нему - комментим и внизу пишем свое.
Михаська; +1 Ответить
20. v.yaunzhekars@gmail.com 18.11.15 12:54 Сейчас в теме
Насколько я понял автора, комментарии вида "ТЗ01_НДС" предлагается использовать для связи с проектной документацией, и это полезно.
Позволяет узнать, зачем здесь этот код.

На мой взгляд
    Комментарии, поясняющие алгоритм или тонкости реализации в коде не нужны. Лучше писать понятный код. Если код нуждается в комментарии, то он также нуждается и в рефакторинге.

    Исторические комментарии вида "//AKA Vasili 31.11.2014", тоже бесполезны. Что даст информация о том, когда и кем добавлен код? Код не для этого. Для того чтобы узнать, кто и когда вносил изменения, лучше пользоваться хранилищем

    Комментарии призванные отличить типовой код от доработанного. Лучше что бы их тоже не было. Вставку на вызов собственной функции в собственном модуле можно отличить и без комментариев. А вставки целых алгоритмов в типовой код больше напоминают костыли, и им, конечно же, нужны комментарии. Если что то добавляешь, то лучше это реализовать в отдельных объектах и модулях. А если просто подправляешь типовой алгоритм по месту, то смирись с тем что это костыль, и напиши комментарий.
o.nikolaev; mrXoxot; +2 2 Ответить
24. klinval 346 18.11.15 14:15 Сейчас в теме
(20) Vova1900,
Комментарии, поясняющие алгоритм или тонкости реализации в коде не нужны. Лучше писать понятный код. Если код нуждается в комментарии, то он также нуждается и в рефакторинге.

Я смотрю вы идеалист. Если вы пишите код на 1000+ строк и он без единого комментария понятен любому - то я вам завидую.
Исторические комментарии вида "//AKA Vasili 31.11.2014", тоже бесполезны.

У нас исторические комментарии совмещены с описанием и номером заявки. Т.е. коммент вида:
//<Определенный наш уникальный открывающий комментарий из 4 символов> Фамилия Дата КраткоеОписание (номер заявки в нашей IT системе)
Закрывающий коммент такой-же только маленько другой уникальный закрывающий тег. Т.е. мы сразу открывая модуль можем найти поиском все наши изменения. Видим кто, когда и зачем внёс. Если что-то непонятно есть номер заявки и по нему можно найти подробную информацию.
Что даст информация о том, когда и кем добавлен код? Код не для этого. Для того чтобы узнать, кто и когда вносил изменения, лучше пользоваться хранилищем

А если в модуль вносил изменения более 1 человека более 10 раз. Что вы увидите в хранилище: Иванов когда-то что-то внёс, Петров и Сидоров. А кто конкретный код внёс непонятно, надо тратить много времени на анализ хранилища. Хранилище 1с в этом плане недостаёт функционала.
А сама по себе быстрая информация кто внёс даёт возможность найти человека которого можно спросить какие-либо нюансы реализации (вместо курения кода) или можно ему перекинуть свою задачу, раз он всё-равно в курсе. Дата даёт возможность быстро понять когда этот механизм был внедрён и заработал.
Vladimir Litvinenko; +1 Ответить
23. softcreator 18.11.15 13:32 Сейчас в теме
Я извиняюсь, а чем вам хранилище конфигурации не подходит?
Отправляем в него ту же типовую при создании хранилища, а затем пилим ее как нужно нам или заказчику. Преимущества: быстрый откат и возможность сравнения версий.
GnatyukMV; v.yaunzhekars@gmail.com; +2 Ответить
26. fomix 33 18.11.15 17:30 Сейчас в теме
(23) softcreator, Хе-хе, а если Хранилище наипнется, что тогда делать будем, а?! Или место в старом закончится и придется новое делать, а?!
25. Pover 18.11.15 17:27 Сейчас в теме
К счастью на комментарии не распространяются жесткие правила. Это что то типа стиля программиста. У каждого он свой.
Полезно для посмотреть а как у "АКА Васи"
28. Bassgood 1501 19.11.15 23:25 Сейчас в теме
(0) По пункту три - с версии 8.3.5, на сколько помню, для обрамления новых процедур вместо комментов можно использовать области #, выглядят они куда более симпатичнее.
29. mrXoxot 3212 19.11.15 23:38 Сейчас в теме
(28) Bassgood,
Да, но проблема осталась та же. #КонецОбласти будет отображаться в сравнении и объединении. Поэтому либо не ставить такие процедуры в конец, либо не ставить такие области.
30. Bassgood 1501 19.11.15 23:44 Сейчас в теме
(29) а что мешает ставить их в начало модуля, чтобы было сразу видно какие процедуры свои мы туда напичкали?
31. klinval 346 20.11.15 09:21 Сейчас в теме
(30) Bassgood, как вариант, но если мы обрамляем свои процедуры комментариями или #Областями то последний комментарий или #КонецОбласти попадёт в типовом сравнении к первой типовой процедуре (см. приложение).
Прикрепленные файлы:
32. пользователь 27.04.25 22:36
Сообщение было скрыто модератором.
...
Для отправки сообщения требуется регистрация/авторизация