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

08.09.20

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

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

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

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

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

  

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

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

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

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

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

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

См. также

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

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

04.05.2026    517    YA_2060655612    8    

8

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

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

29.04.2026    457    _apelsin4ik    0    

3

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

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

21.04.2026    1509    YA_2060655612    6    

11

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

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

20.04.2026    7883    806    KHoroshulinAV    49    

67

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

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

17.04.2026    556    chuprina_as    4    

4

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

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

20.03.2026    1256    ksnik    4    

5

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

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

17.03.2026    1835    IgorVasilyev    54    

27

Рефакторинг и качество кода Программист 1С:Предприятие 8 1С:Комплексная автоматизация 2.х 1C:ERP Бесплатно (free)

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

09.02.2026    1923    Eugen-S    10    

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

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

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

Немного другой подход к полезному коду, который просто именно сейчас не нужен. Его лучше хранить где-то еще, предварительно оформив в нормальный метод. Где угодно - в txt файлах, в базе разработчика и т.п. Так его и найти будет проще и рабочую базу он не "загрязняет".
2. awk 745 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С. Даже не представляю как это быстро проверить в любой системе контроля версий. А комментарии очень выручают, равно как и использование префиксов для собственных реквизитов и объектов.
Для отправки сообщения требуется регистрация/авторизация