Метод борьбы с большим количеством комментариев в коде

08.09.20

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

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

В нашей компании стандарт разработки запрещает разработчикам удалять «чужой» код, приходится его комментировать и дополнительно обрамлять свои изменения в комментарии. Конечно мы знаем и про GIT (даже используем в нескольких проектах) и возможности хранилища просмотреть историю изменений. Но, согласитесь, зачастую удобно, просто читая код, иметь всю информацию об изменениях (мы фиксируем номер наряда, ФИО разработчика, дату изменений и краткий смысл).  Конечно  наиболее изменяемые фрагменты становятся трудно читаемыми. Для борьбы с этим мы используем следующий подход:

  1. В модуле выделяется область «Архив кода», располагать такую область лучше в конце модуля
  2. Разработчик выделяет «замусоренный» комментариями код и используя меню "ПКМ -> Рефакторинг -> Выделить фрагмент" создает процедуру. Название процедуры лучше давать по смыслу выделенного фрагмента. Соответственно и сам фрагмент должен иметь осмысленный алгоритм, возможно это будет процедура или функция целиком.

  1. Полученную процедуру копируем в область Архив кода и к названию добавляем суффикс – дату переноса. Полезно также заключить архивную область в конструкцию #Если Сервер и НЕ Сервер. Тем самым гарантируем, что наш архив практически не будет влиять на производительность.
  2. Процедуру, которая будет исполняться, очищаем от лишних комментариев. И снабжаем своим, в котором указано, где посмотреть старый вариант. В итоге получится вот так:

  

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

Скажите, а как вы боретесь с излишней закомментированностью кода?

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

Комментарии код оформление

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

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

См. также

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

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

09.06.2026    581    Repich    3    

3

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

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

04.06.2026    646    IgorVasilyev    29    

4

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

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

7 стартмани

19.05.2026    2922    27    KHoroshulinAV    7    

13

Запросы Рефакторинг и качество кода Программист Стажер 1С:Предприятие 8 Бесплатно (free)

Есть запросы, которые сразу вызывают подозрение: десятки соединений, множество временных таблиц, объединения, группировки и длинный список условий. Но чаще проблемы прячутся в другом месте — в запросах, которые выглядят вполне приемлемо. Пара обращений через точку, отбор после виртуальной таблицы, РАЗЛИЧНЫЕ «чтобы убрать дубли», большой список в параметре, реквизит регистратора через составной тип — и вот уже на тестовой базе все летает, а в рабочей базе отчет открывается минуту. Разберу такие случаи из практики: не синтаксические ошибки, а именно запросы, которые формально нормальные, но на больших данных начинают вести себя плохо.

04.05.2026    1897    YA_2060655612    11    

9

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

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

29.04.2026    980    _apelsin4ik    0    

5

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

Код в 1С редко начинает тормозить сразу. Намного чаще он долго выглядит нормальным, а проблемы проявляются позже — когда растут данные, пользователи и количество доработок. В статье разбираю типичные причины такой деградации: запросы в цикле, лишние ПолучитьОбъект(), тяжёлые формы и обработку “по одному”. Статья практическая: с примерами, типичными ошибками и понятными признаками того, что код уже плохо масштабируется.

21.04.2026    2030    YA_2060655612    6    

11

Инструментарий разработчика Рефакторинг и качество кода Программист 1С:Предприятие 8 Бесплатно (free)

Инструмент для тех, кто устал читать модули по 50 тысяч строк и искать ошибки глазами. MetaVision загружает выгруженные файлы конфигурации и за секунды строит графы функций, находит уязвимости и подсвечивает проблемы производительности. Ключевые возможности: Визуализация логики функций (графы условий, циклов, транзакций и вызовов). Статический аудит безопасности (RCE, SSRF, COM-инъекции, пароли в коде). Поиск проблем производительности (запросы в циклах, вложенные блокировки). Полнотекстовый поиск по всем модулям конфигурации. Статистика по объектам и функциям. Безопасность: Программа работает строго локально. Код вашей конфигурации не отправляется в интернет и не анализируется на сторонних серверах. Попробуйте MetaVision сегодня — узнайте, что скрывает ваш код.

20.04.2026    11756    1244    KHoroshulinAV    56    

90

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

Как быстро разобраться в чужом коде? Как не забыть через полгода алгоритм работы своего собственного кода? Как наглядно проектировать? Ответам на эти вопросы посвящена данная публикация.

17.04.2026    892    chuprina_as    4    

4
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. user1350278 08.09.20 10:46 Сейчас в теме
Как правило, многочисленный закомментированный код, спустя месяц-другой, не нужен уже никому. Для того чтобы понять, что делал этот код и почему, придется абстрагироваться от всех более поздних наслоений (и не обязательно в модуле, где вносились изменения, они же могут быть связаны с изменениями где-то еще), а не просто прочитать несколько строчек кода.

Вы правильно заметили - для ведения истории нужна система контроля версий с нормальными комментариями коммитов, а не попытка ее промоделировать вынося "замороженный" код в модуль.

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

Немного другой подход к полезному коду, который просто именно сейчас не нужен. Его лучше хранить где-то еще, предварительно оформив в нормальный метод. Где угодно - в txt файлах, в базе разработчика и т.п. Так его и найти будет проще и рабочую базу он не "загрязняет".
2. awk 746 08.09.20 13:08 Сейчас в теме
Нарушение стандартов у вас, однако.
Закомментированный фрагмент кода, недостижимый код
Программные модули не должны иметь:
1. Закомментированных фрагментов кода,
2. Фрагментов, которые каким-либо образом связаны с процессом разработки (отладочный код, служебные отметки, например, TODO, MRG и т.п.)
3. Фрагментов связанных с конкретными разработчиками этого кода

Недопустимо оставлять подобные фрагменты в коде после завершения отладки или рефакторинга.
https://its.1c.ru/db/v8std/content/456/hdoc п.3
ИНТЕГРА; gigabyte_artur; user986734; +3 Ответить
3. stepan_s 09.09.20 06:24 Сейчас в теме
на самом деле в практике к сожалению часто бывает что задача трансформируясь во времени приходит к своему изначальному, так сказать первозданному виду :).
В этом случае очень помогает подобное версионирование, на больших задачах.
но реализовывать все же лучше средствами или хранилища, или говорят еще git может помочь :)
Но если задача мала - то оставлять коды опасно. т.к. соблазн их анализировать будет, а это потеря времени.
Итого:
Стандарты разработки (не только в 1С) говорят низя в продакшн "засирать" код.
Если нужна историй - хранилище вам в помощь.
4. tambu 82 10.09.20 03:24 Сейчас в теме
Прошу прощения, не каждый день захожу на ИС. Отвечу всем сразу. Специально упомянул в публикации и про гит и про хранилище, мы их также используем. Однако, что гит, что хранилище - это долго. Практика показала что подобные комментарии, хоть и нарушают стандарты, экономят очень много времени. У нас большие конфигурации и их много. Несколько десятков программистов, причем половина внештатников. Помимо программистов есть АБД, которые могут "глянуть" код, но не меняют его (значит и доступов в хранилище не имеют). Главное в наших комментариях - номер наряда. Далее в сервис-деске мы получим всю необходимую информацию. В том числе и о связанных изменениях (так как в нарядах зафиксированы даже изменения в других базах, если они производились в ходе работ). Причем сделать это сможет любой, кто получил доступ в код, ему не обязательно получать доступ в хранилище (иногда это десятки минут просто на подключение, плюс добавьте бюрократию) или настраивать у себя гит.
Рамзес; +1 Ответить
5. dhurricane 11.09.20 09:00 Сейчас в теме
(4)
Практика показала что подобные комментарии, хоть и нарушают стандарты, экономят очень много времени.
Опишите, пожалуйста, это поподробнее. Мне правда интересно. С одной стороны Вы указали, что "мусор" в коде усложняет чтение кода, с другой - его наличие облегчает анализ истории изменения. Как Вы достигли того баланса для себя, что описали в статье? Как оценили экономию времени с учетом трудозатрат на чтение "замусоренного" кода? Как часто приходится обращаться к истории изменений одного фрагмента? Зачем нужен быстрый доступ к истории кода, когда есть описание в сервис-деске текущей реализации?
6. tambu 82 14.09.20 09:38 Сейчас в теме
У нас достаточно большая организация и, как следствие, есть определенная бюрократия. Чтобы получить доступ к хранилищу/гит нужно будет подать заявку в сервис-деск. Отработают её не мгновенно. Да и подключение к самому хранилищу порой занимает около часа (базы большие).
Между тем, часто возникает ситуация, что для исправления ошибки или для небольших изменений привлекают разработчиков, не имеющих опыта в данной конфигурации. Им разворачивают копию базы, глушат регламенты и "вперёд". В процессе работ бывает необходимо узнать кто и зачем вносил определенные изменения. Вот тут и помогают наши комментарии. Видно автора, видно дату изменений, видно номер наряда в сервис-деске. Далее можно либо связаться с автором, либо углубленно изучить данные в наряде (там есть целый раздел, посвященный внесенным изменениям). Зачастую в комментариях сразу описан смысл изменений или другая важная информация, что позволяет лучше понять код.
Кстати, не сказать что часто, но бывают случаи, когда получив инцидент и выяснив заказчика изменений мы сообщаем эту информацию автору инцидента и больше ничего делать не приходится. Происходит это тогда, когда не все заинтересованные бизнес-подразделения получают информацию об изменениях и считают, что программа "сломалась". И самое удивительное, когда такие "расследования" показывают, что программа была изменена 3-4 года назад, а пользователи только сейчас заметили, что поведение программы их не устраивает. Тут уже человеческий фактор.
Ну и "вишенка на торте" - мы заканчиваем разработку программы индексации изменений кода. Вкратце - мы парсим код, ищем номера нарядов и фиксируем измененные объекты. Сейчас эту информацию разработчики вносят вручную, в дальнейшем будем получать автоматически. Данная база будет помощником, например архитекторам решений и тех. поддержке, в моменты обновления релизов. Зная какие наряды вошли в релиз, будет получен и список измененных объектов. А значит мы сразу увидим, если чего-то недостаёт или наоборот что-то лишнее.
7. kosmo0 113 18.09.20 15:46 Сейчас в теме
Эх, а в идеальном мире в конфигураторе есть галочка - показывать весь код или показывать только рабочий код. В первом случае видно всё всё, включая закомментированный старый неиспользуемый код. Во втором - только код который используется в текущем релизе. И даже, для уменьшения веса, фрагменты старого и/или неиспользуемого кода хранятся отдельно.


ps. А в принципе можно же использовать области. Единственно невозможно массово разворачивать/сворачивать области с заданными наименованиями. (а еще нашел в настройках такую сущность как комментарии областей - что это)
8. herfis 522 18.09.20 16:40 Сейчас в теме
Любые комментарии, пытающиеся взять на себя задачи системы контроля ревизий - это зло.
Кое-как они способны приносить пользу только пока это одноразовые "заплатки" на фоне в целом статичного года. Чем динамичнее код - тем больше вреда и хаоса они привносят.
Ну а комментарии призванные улучшить читабельность кода по определению не могут являться "лишними".
Другое дело, что "чистый" код вообще не требует комментариев. Но жизнь штука сложная, поэтому иногда комментарии нужны :)
Ну и крупные блоки иногда удобно нотировать для более быстрой навигации и быстрого понимания на уровне крупных блоков.
Если многим людям кроме разрабов требуется доступ к ревизиям, возможно стоит подумать о собственном гитовом сервере репозиториев с веб-мордой, по типу гитхаба, только в рамках организации. Я не настоящий сварщик, но про подобные решения слышал.
9. tambu 82 22.09.20 05:24 Сейчас в теме
Один из типичных кейсов использования комментариев - обновление релизов измененных типовых решений. Оставим за кадром использование расширений (я пока не видел удобных инструментов для расширений, которые сравнимы с показом дважды измененных объектов).
Так вот при обновлении релизов крайне полезно сразу видеть, что код менялся нами, а не разработчиками 1С. Даже не представляю как это быстро проверить в любой системе контроля версий. А комментарии очень выручают, равно как и использование префиксов для собственных реквизитов и объектов.
Для отправки сообщения требуется регистрация/авторизация