Без комментариев!
Разработка - Рефакторинг и качество кода
Все примеры в данной статье - вымышленные, однако созданы "по мотивам" реально встреченных комментариев.
По роду работы мне приходится читать и редактировать очень много кода. И меня огорчает огромное количество комментариев в коде, с которым я встречаюсь. Считаю, что комментарии вредны, опасны и не нужны. Комментарии мне настолько не нравятся, что в своем коде принципиально их не использую (кроме отдельных случаев, о них ниже). Обосную свое отношение.
Для начала изложу свои соображения по поводу того, почему вообще эта тема поднимается.
Обратимся к библии программиста 1С - документу "1С:Предприятие 8. Система стандартов и методик разработки конфигураций", раздел "Тексты модулей".
Позиция 1С по поводу комментариев в коде такова - комментарии можно оставлять, при этом есть некие условия по форматированию комментариев.
Попробую классифицировать типы комментариев и понять причины, что заставляют программистов оставлять комментарии в своем коде. по моим наблюдениям основные типы комментариев такие:
- Указание автора кода и номера задачи (авторский комментарий)
- Сохранение чужого (старого) кода
- Пояснение того, что делает код
- Отражение событий в мире и организации
Разберу каждый тип подробнее.
1. Указание автора кода и номера задачи
Это так называемый "авторский комментарий".
Наверное даже не надо ничего пояснять. Это традиция. Так все делают и будут делать. Когда не было технологии выгрузки исходного кода в git, комментарий был единственным способом указать себя автором изменения. У многих даже настроены шаблоны - вставка начала своего кода, вставка окончания и всякое подобное. Вот пример шаблона, который вставляет имя пользователя конфигуратора и текущие дату и время.
// Добавлено <?"""", ИмяПользователя> <?"""", ДатаВремя, """">
Такое комментирование порождает нагромождения, через которые весьма сложно пробираться:
// Вставка Иванов 11.10.2019 14:35:17
ДанныеЗаполнения.Вставить("Приоритет", ПриоритетПоПартнеру(Заказ.Партнер));
// КонецВставки Иванов 11.10.2019 15:35:17
//Смирнов 2020-01-01
ДанныеЗаполнения.Вставить("Комментарий", "Создан автоматически из обработки");
// Начало изменения Петров 25-01-2021
// Заявка 33555 - указать адрес доставки
ДанныеЗаполнения.Вставить("АдресДоставки", НовыйАдресДоставки);
// Конец изменения Петров 25-01-2021
У нас есть некая структура, которая затем используется для заполнения какого-то объекта. Это самый невинный пример, но тут мы видим на 3 строчки кода 6 строчек комментариев. Зачем мне знать сейчас, в 2023 году, что три года назад в структуру добавили ключ Приоритет, а позже добавили еще два ключа? Сейчас в этом нет никакого смысла, два программиста, оставившие эти комментарии, уже не работают у нас, а система учета заявок и номер задачи неактуальны - мы перешли на другую систему учета заявок.
Эти комментарии мешают пониманию кода. Банально приходится читать больше текста, они отвлекают от сути.
Моя основная претензия в том, что такие комментарии устаревают и по прошествии какого-то времени их наличие скорее раздражает, чем вызывает позитивные чувства (даже у любителей комментариев).
Хорошо, но авторские комментарии о "свежих" изменениях полезны? Нужны ли сейчас такие комментарии? Большой вопрос.
EDT идет уверенной поступью и все больше и больше команд переходят на разработку в EDT. Но даже если вы работаете в конфигураторе, уже давно есть инструменты, с помощью которых выгрузка исходного кода становится легкой и приятной. А если в вашей компании это не принято, вы всегда сможете выгрузить в гит самостоятельно, прямо на своем компьютере.
Git Blame - это технология, показывающая автора каждой строки кода.
Здесь я привел скриншот из модуля, открытого в Visual Studio Code. При наведении курсора на строку кода показывается, кто и когда эту строку изменил. Посмотрите, какая красота! Ничто не отвлекает от чтения и понимания кода, а если потребуется узнать, кто и когда написал какую-то строку - вот она, эта информация под рукой.
Кажется, можно перестать выделять свой код авторскими комментариями, правда?
2. Сохранение чужого (старого) кода
Эта причина иногда также вызвана соглашениями, принятыми внутри команды. Некоторые команды практикуют такой стиль написания кода - если надо что-то исправить, комментируем "старый" код, добавляем рядом свой, да еще и обрамляем все это авторским комментарием. Но часто программисты по собственной инициативе делают так же - старый код остается закомментированным, всегда можно вернуться к нему, убрав символы комментариев.
Я считаю такие комментарии мусором. Как правило, такой закомментированный код не пригождается впоследствии. Помните поговорку про "ничто не бывает таким постоянным, как временное"? Комментарии остаются балластом и мешают пониманию основного кода модулей.
К тому же, в нашей библии (стандарты разработки) есть специальное указание - в модулях недопустимо иметь закомментированные фрагменты кода.
Вдумайтесь, стандарты разработки ЗАПРЕЩАЮТ оставлять закомментированный код, а мы так делаем повсеместно!
Во всех вакансиях от программиста 1С требуют знание стандартов разработки и все соискатели рапортуют, что следуют стандартам. Однако это не мешает оставлять после себя шлейф закомментированных строк.
Встречал документ, в модуле которого 90% кода было закомментировано, причем блоки закомментированного кода были смешаны с рабочим кодом. Нужно ли объяснять, каково было дорабатывать этот модуль?
3. Пояснение того, что делает код
На первый взгляд - похвальное желание. Всем хочется, чтобы их код был понятен для понимания. Давайте оставлять поясняющие комментарии! Но и тут не все так просто.
Часто пояснение кода превращается в игру с капитаном Очевидность.
// Удалим элементы отбора Контрагент, если включена ФО ИспользоватьПартнеровКакКонтрагентов
Если ПолучитьФункциональнуюОпцию("ИспользоватьПартнеровКакКонтрагентов") Тогда
КомпоновкаДанныхСервер.УдалитьЭлементОтбораИзВсехНастроекОтчета(КомпоновщикНастроекФормы, "Контрагент");
КонецЕсли;
// Удалим элементы отбора Организация, если не включена ФО ИспользоватьНесколькоОрганизаций
Если Не ПолучитьФункциональнуюОпцию("ИспользоватьНесколькоОрганизаций") Тогда
КомпоновкаДанныхСервер.УдалитьЭлементОтбораИзВсехНастроекОтчета(КомпоновщикНастроекФормы, "Организация");
КонецЕсли;
// Удалим элементы отбора Склад, если не включена ФО ИспользоватьНесколькоСкладов
Если Не ПолучитьФункциональнуюОпцию("ИспользоватьНесколькоСкладов") Тогда
КомпоновкаДанныхСервер.УдалитьЭлементОтбораИзВсехНастроекОтчета(КомпоновщикНастроекФормы, "Склад");
КонецЕсли;
// Удалим элементы отбора ЕдиницыКоличества, если не включена ФО ИспользоватьЕдиницыИзмеренияДляОтчетов
Если Не ПолучитьФункциональнуюОпцию("ИспользоватьЕдиницыИзмеренияДляОтчетов") Тогда
КомпоновкаДанныхСервер.УдалитьПараметрИзПользовательскихНастроекОтчета(КомпоновщикНастроекФормы, "ЕдиницыКоличества");
КонецЕсли;
Обратите внимание на код выше. Каждый комментарий в нем бессмысленен, так как из кода и так все понятно - имена процедур, функций, параметров говорят сами за себя.
Приведу другой пример - на первый взгляд тут комментарий обоснован. Но почитайте код внимательней.
// отсортируем таблицу запросом по возрастанию даты для дальнейшего использования
Запрос = Новый Запрос;
Запрос.УстановитьПараметр("Приоритеты", Приоритеты);
Запрос.Текст = "ВЫБРАТЬ
| Приоритеты.ДатаЗаписи КАК ДатаЗаписи,
| Приоритеты.Номенклатура КАК Номенклатура
|ИЗ
| &Приоритеты КАК Приоритеты
|
|УПОРЯДОЧИТЬ ПО
| ДатаЗаписи УБЫВ";
В запросе одно - а в комментарии совсем другое. Что произошло? В коде изначально была допущена ошибка или же логика совпадала, но потом код доработали, а про комментарий забыли?
Лучше использовать "говорящие" названия функций и переменных, если надо - выносить участки кода в функции и процедуры с ясными осмысленными названиями. Это хорошая альтернатива комментариям, правда?
4. Отражение событий в мире и организации
У меня есть целая подборка комментариев из кода реальных баз, которые вызывают улыбку, заставляют задуматься или просто рождают чувство легкого недоумения. Я обещал не приводить реальные примеры, поэтому привожу немного отредактированные.
Пример 1
// включил механизм 01.03.2020 года по указанию Ивановой
// выключил механизм 02.03.2020 года по указанию Ивановой. Жаль...
// две недели было потрачено на разработку...
// ПроверитьЦеныПоНовомуМеханизму(Объект, Отказ);
Пример 2
// Всех принудительно заставили работать дома, новый виток короны
//
// Я не очень рад этому
УстановитьУникальныйКодПартнера(Объект);
Пример 3
// Не верю, что это поможет. Это уже третий подобный механизм в базе.
// Может быть уже скорректируем процессы, которые приводят к косякам?
ПроверитьУникальныйКодПартнера(Партнер, Отказ);
Наверное в этих комментариях есть большой глубокий смысл. Но такой код сложно назвать чистым.
Когда комментарии нужны?
Есть момент, когда комментарии все-таки нужны. Более того, они необходимы. В тех же стандартах разработки (раздел Описание процедур и функций) утверждается, что они обязательны. При создании экспортной процедуры или функции мы обязаны составить комментарий, состоящий из секций "Описание", "Параметры", "Возвращаемое значение" и "Пример". Формально это комментарий, написанный по определенным правилам. По сути - это пояснение для программиста, о том, как правильно использовать функцию. Для конфигуратора или EDT это пояснение используется для контекстной подсказки (а в EDT еще и для типизирования). Это очень полезная штука.
Забавное наблюдение: как правило люди, активно пишущие ненужные комментарии, забывают указывать описания экспортных процедур и функций.
Заключение
Использовать или не использовать комментарии в коде 1С - решать вам.
Стандарты разработки не запрещают их использовать, а соглашения внутри команды могут обязывать оставлять авторские комментарии или обрамлять комментариями старый код.
Возможно, я слишком серьезно отношусь к недостаткам комментирования и все гораздо проще. А что вы думаете по этому поводу?
Вступайте в нашу телеграмм-группу Инфостарт
Инструментарий разработчика комментарии самодокументированный код
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
См. также
Нейросети Рефакторинг и качество кода Запросы Разработчик 1С 8.3 Абонемент ($m)
Нейросеть написала запрос или процедуру для вашей базы 1С, и непонятно, все ли имена в нём настоящие. Обработка компилирует текст без выполнения, сверяет его с метаданными этой базы и к каждой ошибке пишет настоящее имя, например ВНаличииОстаток вместо выдуманного КоличествоОстаток. Список ошибок с подсказками одной кнопкой копируется обратно в чат с моделью.
10 стартмани
02.11.2026 353 1 nedomolkov.ivan 1
Рефакторинг и качество кода Разработчик 1С:Предприятие 8 Россия Бесплатно (free)
Одна проверка в обработчике кнопки может выглядеть достаточной, пока ту же операцию не вызовут из другого места. На примере управляемой формы разберём, почему так происходит, как разместить проверку в общей серверной функции и чем отличается удобная проверка ввода от обязательного условия выполнения операции.
29.10.2026 374 YA_777378709 0
Рефакторинг и качество кода Разработчик Бесплатно (free)
Рассказываем, почему качественный код – это не техническая прихоть, а актив, который помогает бизнесу быстрее адаптироваться к изменениям и запускать новые фичи без бесконечного преодоления техдолга. Показываем, как объяснить бизнесу ценность рефакторинга через понятные признаки: замедление разработки, неточные оценки, страх перед legacy и хрупкость системы. Разбираем, почему неправильный рефакторинг может быть дороже его отсутствия, какие анти-паттерны ломают процесс и как не превратить улучшения в бесконечную переделку ради переделки. Объясняем, как сделать рефакторинг частью культуры команды: договориться с бизнесом, научить разработчиков видеть проблемные места, закрепить правила и поддерживать улучшения на уровне тимлидов, архитекторов и всей команды.
28.10.2026 486 Pavel791 0
Рефакторинг и качество кода HighLoad оптимизация Системный администратор Разработчик Стажер 1С 8.3 Абонемент ($m)
Если к HTTP-сервису 1С обращаются сразу несколько программ, сколько запросов в секунду он успеет обработать? Я опубликовала простой HTTP-сервис на нашей "подопытной" конфигурации «Нано-УТ» (файловая база, Apache, без прав администратора) и нагрузила его скриптом на Python. Ответ: около 15-16 запросов в секунду, сколько бы клиентов ни обращалось одновременно. Запросы ждут своей очереди, и при 32 клиентах ответ приходит через 2 секунды вместо 64 мс. Заодно разобрала скрипт из первого варианта статьи: он «проверял» сервер, который отвечал по одному, и считал ошибки вместе с успешными ответами. В архиве исправленный скрипт, учебный сервер, HTTP-сервис для 1С и инструкция по запуску.
1 стартмани
23.10.2026 518 Ninel_S 3
Рефакторинг и качество кода Разработчик 1С 8.3 Абонемент ($m)
Запустили Analyzer 1C 2.7.65 на промышленной конфигурации (596 модулей, 13 669 функций) и исследовали перегруженные функции (до 1887 строк), циклические зависимости и экран «Циклы» (кольцо из 64 модулей). Разобрали, почему популярные метрики (McCabe, связность) не представлены в продукте вендора, и составили пошаговый план разделения модуля. Привели проверенный платформой 8.3.27 пример до и после рефакторинга и выявили скрытую ловушку загрузки модулей с точкой в имени.
9 стартмани
19.10.2026 455 Ninel_S 2
Рефакторинг и качество кода EDT СКД Разработчик 1С 8.3 1С 8.5 1С:Бухгалтерия 3.0 Бесплатно (free)
Одиннадцать граблей схем компоновки, которые не видно в конструкторе и не ловит EDT, на реальных отчетах БП КОРП. Формат числа задается в двух местах, и условное оформление варианта перебивает формат поля. Ресурс складывает штуки с часами, и помогает выражение «только когда единица одна». Ресурс пуст в детальных записях, параметр не появляется в шапке без userSettingID, valueListAllowed ломает границы периода, Остатки и СрезПоследних с параметром периода падают с «Несоответствием типов», title без xsi:type дает «Исключение XDTO» при загрузке. В конце код проверки схемы из файла до обновления базы, сводная таблица и чеклист.
16.10.2026 529 Konstmax13 2
Инструментарий разработчика Нейросети Рефакторинг и качество кода EDT Разработчик 1С 8.3 1С 8.5 1С:Бухгалтерия 3.0 Бесплатно (free)
Как ИИ-агент (Claude Code) работает в живом EDT-проекте 1С:Бухгалтерии КОРП 3.0: из чего собрать стенд с MCP-сервером для EDT, как ставить задачи агенту, где он ломает проект и какие проверки это ловят. Реальные случаи: рукописные метаданные, ронявшие конфигуратор; четыре дня зависшего обновления из-за порядка блоков в Rights.rights; ошибки, которые EDT пропускает, а платформа нет; сплошная сверка вместо «вроде работает». В приложении шаблон CLAUDE.md, шаблон правила, чеклист перед обновлением базы и скрипты проверки ролей и схем СКД.
15.10.2026 3472 Konstmax13 11
Рефакторинг и качество кода Тестирование QA Разработчик 1С 8.3 Абонемент ($m)
Инженерный анализ влияния (Impact Analysis) при изменении общего метода в 1С:Предприятии: почему штатный поиск ссылок скрывает 99% зависимостей и как обратный обход графа вызовов выявляет 370 скрытых потребителей на глубине 3 уровней. В статье — верификация сквозной цепочки обмена с маркетплейсом; в архиве-компаньоне — автономный BFS-анализатор на Python, слепки графа и план регрессионного тестирования.
1 стартмани
12.10.2026 325 Ninel_S 0
Комментарий сжат номер обращения в базу поддержки, автор и дата.
Версионность кода в истории хранилища конфигурации, или git (если это есть, то старый код можно не хранить в коде, если нет, то хранить в коде).
Автор и дата - это стандартно все добавляют, также помогает определить быстро время и ответственному позвонить быстро узнать в чем суть.
Можешь не отвечать, я вижу ты все заранее осуждаешь. Всех благ.
А если что не так работает то по любому будешь дописывать не смотря в тикер который скорее всего уже потеряется.
И что вам мешает свою портянку вести отдельно??? если пррограммист добрался дострочек кода то очевидно они ему нужны толку от ваш рисований имен?
тех заданий по ходу исполнения стока раз меняется что вообще фиолетово что там написано, я уж молчу что потом как правило приходится допиливать.
По сути такое засирание кода выгодно только франчам, ну сидели бы засирали в гите, или хранилище там есть для этого функционал нафига в код писать?
1) Сохранять обновляемость конфигурации
2) Обеспечить читаемость кода
3) Сохранить историю изменений кода и причины изменения
- а кто будет делать ремонт в твоей квартире и по какому дизайну тебе самому решать, ведь даже самую хорошую историю могут пети и васи испортить.
Обмен дорабатывал не типовой в типовой конфе через расширение?
Какие-то составные типы перехватывал в расширение?
Проекты на 10000 часов доработок делал?
Можешь не отвечать мастер-фломастер, ты больше по какашкам в горшках ))
Такие комментарии особо помогают в двух моментах:
1. Быстрое выявление и выделение внесенных изменений в код. Особенно удобно при обновлениях.
//++
код
//--
2. Редко, но "метко" бывает так.... заказчик (например главный бухгалтер) сначала требует изменить формулу вопреки типового решения от 1С, а потом, спустя год (при аудите и проверках) начинает обвинять, что это косяки 1С и это у ИТ отдела 1С неправильно считает - и в этом случае такие записи для ИТ отдела на вес золота.
2. ты показываешь комментарий и она верит? Может служебку поискать, Бред полный.
Недобросовестное исполнение своих обязанностей программистов, повторно изменяющих код, не должно автоматически обвинять первоначальных программистов, написавших комментарий.
По классическим правилам, эти комментарии можно заменить на разделение блока кода на несколько функций (которые так и будут называться: "ОбращениеКHTTPСервису" и т.д.), но, во-первых, нагромождение функций иногда мешает сосредоточиться, а во-вторых, для некоторых механизмов удобнее держать весь текст на экране (если он туда помещается).
Как знать, может твой метод еще будут использовать, если он хорош)
Идеально экспортным сделать с комментом по стандарту - вот тут уже можно все нюансы описать)
1. Как минимум, второстепенный код можно вынести в отдельные методы, чтобы он не мешал при чтении основного кода. Например, вынести в отдельные методы предварительные проверки, логирование и т.д.
Например, я часто делаю так:
Если Не <ТутВызовФункииПредварительнойПроверки> Тогда
Возврат;
КонецЕсли;
<ТутОсновнойКод>
2. В методах можно использовать оператор "Возврат". Возврат позволяет избавиться от многоуровневых вложенных конструкций «Если» или сложных условий в этой конструкции.
Например, та же функция предварительной проверки у меня часто выглядит так:
Если Не Условие1 Тогда
Сообщить(…);
Возврат Ложь;
КонецЕсли;
Если Не Условие2 Тогда
Сообщить(…);
Возврат Ложь;
КонецЕсли;
Возврат Истина; Показать3. Часто бывает такое, что читаешь портянку кода на несколько экранов, и тебе нужно внести в неё какое-то изменение, которое касается конкретной части функционала. Находишь точку, в которую можно внести изменение, но ты не уверен, что это единственная точка, возможно, выше или ниже по коду тоже затрагивается этот функционал. Приходится внимательно просматривать код целиком, убеждаться, что остальные куски никак не влияют. Если же разбивать код на методы, то это снижает связность кусков кода, программист вынужден реализовывать методы так, чтобы они решали каждый свою задачу (иначе получается монструозная конструкция из методов с большим количеством параметров). И с большей уверенностью можно внести изменения только в нужный тебе метод.
4. Если не дробить код на слишком мелкие методы и давать понятные имена методам, то упрощается навигация по коду, то есть проще добраться именно до того функционала, который тебе нужен, не отвлекаясь на анализ ненужного функционала
Первый про авторство:
Есть очень полезная задача, которую ни GIT ни EDT вроде бы не решает... Представим себе, что есть большая задача. Разработчик её в любом случае делает в несколько заходов (2-4). Если договориться на старте о том, что комментарий будет содержать ФИО и дату начала работы по задаче, то это становится полезным. У меня появляется возможность через поиск по всем текстам увидеть ВСЕ вставки кода по текущей задаче. Можно не писать фамилию... можно номер задачи только указывать в комментарии и дату начала работы по нему. Информация об этом особенно полезна в момент обновления конфигурации. Уже не раз сталкивался, что приходится переписывать задачу на новый релиз. В такой ситуации очень полезно видеть весь код по этой конкретной задаче вне зависимости от исполнителя даже. Другой пользы для меня нет.
Особенно стоит учесть, что когда ты увольняешься, то СФ у тебя остаётся с наработками на память, а вот GIT и EDT нет!
Вот сейчас в проекте пришлось доставать один механизм для УПП, которому 10 лет! Тогда не было ни GIT ни EDT, ни дыр из которых кричали... А найти весь код по этому механизму помогло ФИО + дата.
Вопрос в другом. А будет ли этот GIT доступен через пару лет?
Сохранять код в разработанных командой документа/обработках и т.д. это конечно же уже лишнее.
Тут конечно вкусовщина, но я сам терпеть не могу код без комментариев! Даже игра с капитаном "Очевидность" имеет пользу.
Приведу в пример мои собственные разработки:
Кейс 1. Обработка по выгрузке и созданию регламентированных табелей из самописной базы для ведения табельного учета.
Эта волшебная обработка в длину 6000 строк кода. Если убрать комментарии - 5500. Могу точно сказать: задолбаешься читать и пытаться понять что там написано! Поэтому комментарии содержат:
-- Описание концептуальных шагов, что и зачем делается. Не всегда есть ТЗ нормальное, часто реальный алгоритм далёк от исходного ТЗ, опять же увольнение из организации с потерей доступа к материалам.
-- Особенности алгоритма, возможно критичные ошибки. Не надо забывать, что Ваши доработки кто-то будет сопровождать! Этот кейс успешно сопровождается уже 1,5 года!
-- В некоторых моментах якобы бессмысленные комментарии, которые помогают быстрее позиционироваться на нужном куске кода. Мне удобнее глазами искать нужное место по зелёным комментам, а не по основному коду! Здесь конечно вкусовщина...
Кейс 2. Конструктор выгрузки данных из ЗУП в Excel. Выгрузка в особый формат для Oracle.
Всё то же самое! Сопровождается уже 3 года!
Кейс 3. Загрузка кадровых данных из Access в УПП.
Имеется ввиду разовая миграция. Несмотря на то, что задача разовая... Но обработка тоже примерно 6000 строк кода. Т.к. исходные данные в кривом формате и сами данные не очень консистентные, приходилось выдумывать дурацкие алгоритмы, для приведения данных в порядок. Эти алгоритмы я УЖЕ не помню! Хотя задача ещё не завершена. И вот по комментам есть возможность понять, что и почему делалось. Опять же описаны особенности! Капитан очевидность тоже присутствует. Это при том, что я полностью соблюдаю стандарты разработки!
Этот кейс мой текущий проект.
Что делаю если нет комментов в коде, а нужно разобраться в чужой большой обработке!? Рисую на бумаге схему работы этого кода. Занимает это немало времени. Комментарии в коде снизили бы эти трудозатраты. Главное помнить, что пишешь это не только и не столько для себя! Тогда проще будет относиться к наличию комментариев.
Это проблема кода. Нужно писать читабельный, самодокументирующийся код. И проблема отпадет, а коментарии станут не нужны
Спасибо за статью!
Рассуждения автора основываются на лично его ситуации. У нас, например сотрудники, оставившие комментарии еще работают, система учета заявок и их номера актуальны, да и выкладывать код во внешнюю систему не имеем права. И обновление без исходного кода трудновыполнимо.
Хотел уже было написать "тупая статья" из разряда "спасибо кэп".... А потом прочитал комменты.
Так же вторая линия поддержки быстрее ориентируется, имея в комментариях номер задачи.
Думаю, комменты - это инструмент. «Использовать» или «не использовать» зависит от организации процесса разработки и поддержки
Если код нуждается в комментариях - это плохой код. Его нужно не снабжать комментариями, а переписать, снабдив говорящими именами.
Есть небольшие исключения. Например, в комментарии может быть задокументирована некая особенность. Но такие случаи довольно редкие
Затем надо ценить время своих коллег, у них не у всех есть время используя трассировку кода разобраться в якобы очень понятном и простом коде, поэтому комментарии ЗНАЧИТЕЛЬНО ускоряют другим понимание как отдельных блоков твоего кода так и инъекций твоего кода в типовой код поставщика.
1С приветствует комментарии к коду, к процедурам, к параметрам, к модулям.
Можно здесь почитать (автор также ссылку в статье приложил)
Огромная благодарность всем кто оставляет пояснения к своему коду.
Даже сам подумай логически, будет ли человек пишущий невнятный код тратить силы его еще и комментировать? Ему же лень написать аккуратно, а комментарий оставить лень вдвойне.
И я не заблуждаюсь, я 20 лет с 1С работаю, и тут всё совсем не идеально. Люди приходят и меняют друг друга очень часто. Тем самым создается такая российская реальность, что если ты что-то разработал и не оставил пояснений, то из этого те кто за тобой придут такую шляпу сотворят, что мама не горюй. И в этом будет именно твоя вина, т.к. тебе лень было код документировать. Да, ты сделал идеально, но не читаемо для других, ну тех кто тупее чем ты, но тоже людей, которые кушать хотят и пришли в 1С ПО разрабатывать и попался им твой идеальный код (а им твоя идеальность что в лоб что по лбу)
P.S> писать грамотный код как ты говоришь - надо однозначно. Полностью согласен, этому в ВУЗ'ах учат. А вот не комментировать(документировать) это вот совсем не нормальное поведение. Я считаю что просто это труд и человеческое время, от этого труда многие уклоняются, так как спешат за баблом.
Мне не лень. Я за правильный подход к документированию. А именно - имена переменных и методов должны документировать код
Это и есть плохой код. Хороший код понятен всем, а не только его автору
К сожалению, в ВУЗах пишут чему угодно, но не писать качественный код
В том и суть, что код и без комментариев может быть прекрасно документирован, и понятен даже школьнику
Оставлять комментарии по делу (а не мусорные комменты) - это труд, многим проще объяснить себе, что этого делать не нужно ))) Лень-то она вперёд человека родилась, заказчик в код не полезет, а бабки рядом лежат, можно их забрать и без комментариев в коде.
Сотрудники = Новый Массив; // Сотрудники младше 18 летСотрудникиМладше18Лет = Новый Массив;Обмен мнениями ведётся с людьми, у которых 20 лет опыта. Скажу за себя, что в моём коде нет описанной тобой ситуации. Иногда в имени переменной или процедуры 50+ символов. В (7) комменте писал абсолютно другие примеры!
Одной из распространенных причин для написания комментариев является низкое качество кода. Вы пишете модуль и видите, что код получился запутанным и беспорядочным. Вы знаете, что разобраться в нем невозможно. Поэтому вы говорите себе: «О, да это стоит прокомментировать!» Нет! Лучше исправьте свой код! Ясный и выразительный код с минимумом комментариев гораздо лучше громоздкого, сложного кода с большим количеством комментариев. Не тратьте время на написание комментариев, объясняющих созданную вами путаницу, — лучше потратьте его на исправление. (с) Роберт Мартин, "Чистый код"
Красиво льёшь мёд в уши...
Этот технический долг - это огромная проблема, которую по факту 1-ый программист не решает. Так оставь по крайней мере комментарий к своему убогому коду для 2-го программиста которому придётся за тобой это исправлять.
// Получим данные об операциях, которые требуется выполнить исходя из данных учетной политики и первичных документов
СоздатьОперацииКВыполнению(МенеджерВременныхТаблиц, ВидыОпераций, Период, Организация, ОтборОрганизаций);ПолучимДанныеОбОперацияхКоторыеТребуетсяВыполнитьИсходяИзДанныхУчетнойПолитикиИПервичныхДокументов(МенеджерВременныхТаблицДляЗапроса, ВидыОперацийПоступлениеПередачиСписания, ПериодЭтотМесяц, ОрганизацияИзШапкиОбработки, ОтборОрганизацийВключенИлиНет)ПолучитьДанныеОбОперациях(МенеджерВременныхТаблиц, ВидыОперацийПоступлениеПередачиСписания, ПериодМесяц, ОрганизацияИзШапки, ОтборОрганизацийВключен)
// Данные об операциях, которые требуется выполнить исходя из данных учетной политики и первичных документов.
//
// Параметры:
// ...
//
// Возвращаемое значение:
// ...
//
Функция ПолучитьДанныеОбОперациях() Показать"Создать" - это процедура, "Получить" - это функция (не изменяет контекст). Нужно внести ясность.
"Выразительность для меня прежде всего означает содержательность имен. Обычно я провожу переименования по несколько раз, пока не остановлюсь на окончательном варианте. В современных средах программирования — таких, как Eclipse — переименование выполняется легко, поэтому изменения меня не беспокоят. Впрочем, выразительность не ограничивается одними лишь именами. Я также смотрю, не выполняет ли объект или метод более одной операции. Если это объект, то его, вероятно, стоит разбить на два и более объекта. Если это метод, я всегда применяю к нему прием «извлечения метода»; в итоге у меня остается основной метод, который более четко объясняет, что он делает, и не сколько подметодов, объясняющих, как он это делает" (с) Рон Джеффрис
Пункт 4 (Отражение событий в мире и организации). Согласен, разумеется :)
Пункт 3 (Пояснение того, что делает код). Тоже частично согласен. Стараюсь давать имена переменным и функциям, "говорящими сами за себя". Избыточные комментарии не пишу
Пункт 1 (Указание автора кода и номера задачи). Не согласен с автором. Веду большое количество компаний. Какие-то из компаний перешли ко мне от других франчайзи или других программистов. Какие-то работают то со мной, то с другими программистами. Есть разные варианты ситуаций. Ведут ли другие франчайзи и другие программисты Git или что-нибудь подобное, мне не изестно. Но очень благодарен им, когда они ставят в коде комментарии, с указанием, кто, когда и что изменил или добавил. Сам тоже обязательно делаю это. Не только для других, но для себя. Когда, допустим, необходимо быстро найти, что было сделано для какой-нибудь компании, которая обращалась к тебе пару лет (месяцев, недель, дней, десятилетий и т.д.) назад.
Пункт 2 (Сохранение чужого (старого) кода). Тоже не согласен с автором. По той же причине, что и указана выше. С уважением отношусь к чужому коду. Поэтому, когда приходится его менять, то не удаляю чужой код, а заключаю его в комментарий, и добавляю запись с необходимым пояснением (см. Пункт 1)
Топикастер из инхаус разрабов и использует гит, а франчи - нет. Для первых авторский комментарий это атавизм, для вторых - необходимость.
1) Что делает функция или процедура. (Каждая процедура или функция должна делать что то одно)
2) Комментарии по вставке изменений в функционал который был разработан вендором (для облегчения обновления).
2) Комментирование костылей которые добавляются в конфигурацию (например, в редакции 3.1.15 в формах списков не работали RLS и код который устранял эту уязвимость необходим был для конкретной платформы. Те кто работают с Z платформой поймут меня по скорости исправления ошибок вендором...).
3) Комментарии при вызове API сторонних разработчиков (хорошо если это компонента о которой можно в MSDN почитать, а если это какая ни будь редкая библиотека?).
4) Комментарии при работе со сложными форматами данных. (Например выгрузки в банк клиент через текстовые файлы - что означает допустим 10-я позиция в строке? Будете искать каждый раз формат файла? А если это банк, который не выставляет в общий доступ описание форматов обмена - будете искать документацию и тратить время?)
5) Комментарии сложных алгоритмов. (Например не каждый может сходу понять как работает транзитивное замыкание Ильдаровича или сложение непересекающихся интервалов запросом).
Вставка номера заявки из системы учета заявок, помогает, но не всегда. Иногда просто не получается по описанию восстановить проблему, по которой этот код был добавлен.
Некоторые люди начитавшись Роберта Мартина с его чистым кодом или другие книги по рефакторингу, начинают применять эти патерны в своей работе бездумно. Тут важен принцип - должно быть понятно другому разработчику, который будет работать с этим кодом после вас и чтобы у него не возникло желание вас после этого убить :).
PS. Не хватает ещё возможности вставлять комментарии в запросе, чтобы они сохранялись после использования конструктора. Когда запрос в 20 строк кода, то ещё можно разобраться, но когда 2-3 тыс. строк и есть места с которыми героически кто то боролся, то без этого никак...
А вот на счет того, что БСП это одна из лучший подсистем я бы конечно посgотрил (но не буду) поскольку это будет тот еще холивар.
1. 70% разработчиков на рынке 1С - говнокодеры! Надеюсь тут спорить особо никто не станет.
2. Примерно 2/3 от оставшихся 30% - это в целом профи, но плевать они хотели на стандарты!
3. Остаётся 10% людей которые реально способны писать вот тот самый качественный код.
4. Эти 10% обычно занимаются решением больших и сложных задач, если они перестанут их комментировать, то ни один из 90% остальных "коллег" нифига в нём не разберется, несмотря на хорошую структурированность кода и соблюдение стандартов.
5. GIT и EDT многими воспринимаются как магические заклинания и люди понятия не имеют что это такое
6. Те кто имеют понятие далеко не все его правильно используют.
Описанное выше вытекает из опыта многолетнего на проектах разного размера.
Теперь внимание вопрос:
Почему Вы по сути с пеной у рта отстаиваете что-то, если это касается всего лишь 10% всего написанного кода????
Может стоит более адекватно смотреть на реальность?! И постараться покрыть 90% реальных ситуаций, а не 10% вымышленных???
Конечно нужно остальные 90% подтягивать к 10%, но процесс это длинный и за 1 день не делается. Хорошо - если через 5 лет пропорция будет 20/80. Идеально - 30/70.
Всем любителям хорошо структурированного кода добро пожаловать в
Ни за 1 день ни за 100 лет - зачем если можно просто написать комментарий?
До тех пор пока будет теория о том, что можно написать какой угодно код (главное снабдить его комментом) - о хорошем коде можно забыть.
Говнокодеры комментарии не пишут никогда.
А говнокомментарии только мешают.
Комментировать нужно уметь, на это нужно время.
Если у тебя нет времени, то не нужно этим оправдывать отсутствие комментариев.
Не писать комментарии - это не ценить время тех кто придет за тобой и порождать риски в эксплуатации системы.
P.S.
Мне как-то мастер ставил кухню, и сверлил стены. Оказалось, что трубы с водой к газовому котлу (установлен в помещении кухни) замурованы в стену и идут снизу.
В итоге мастер устанавливая крепежную ленту для нижних ящиков мне трубу с водой, идущую к котлу, просверлил. В итоге ломали стену и вызывали мастера, который котел ставил. Починили, за тем поставили кухню. + 2 дня не нужных проблем и 10 т.руб. бабок сверху это котловому мастеру-фломастеру.
Если бы мастер-фломастер по котлу оставил на стене или самом котле памятку/комментарии, то лишних телодвижений бы не было.
Многие поймут, кто например, стены сверлил в квартире и пытался понять а как электрика в стенах идет к розеткам.... комментариев то никто не оставил, а сделано всё идеально, претензий нет.
Так и не всякий код можно понять, что он делает, если это, например, расширение по интеграции с Яндекс.Сервисами без комментариев и описания )) просто вот оно есть, а как работает разбирайтесь по коду )))
Кстати, куча «промышленных обработок» не содержат комментов и пишутся в модулях формы…. Вот уж где говнокода море
Диверсанты все равно след оставляют(если только код закрыт, тогда да, наверное, есть что скрывать))), следов не будет, если они вообще ничего писать не будут, иногда кажется, может и не стоило ничего писать))), просто разбираться будешь дольше, нежели с комментами. Delphi не зря вспомнил, у нас много, кто в ней пишет, судя по вакансиям на hh.ru. Как-то писал здесь, что клиент-серверная технология ими использовалась больше 25 лет назад(по крайней мере то, с чем я начал знакомиться в Delphi 5), это та реализация, что в 1С сейчас активно развивается. И подход и обработчики, например OnCreate у формы и т.д., все как у нас сейчас. Это общий подход, должен быть, наверное, неизменным не только у них, и у нас тоже.
Насчет комментов в хелпе Delphi 11.2 сказано следующее, на мой взгляд кратко и по существу:
- Комментарии — это фрагменты текста, используемые для аннотирования программы. Комментарии предназначены только для использования программистом; они удаляются из исходного текста перед синтаксическим анализом.
- Полезно размещать комментарии в верхней части блока, чтобы объяснить его назначение.
- Полезно размещать комментарии перед объявлением класса.
- Полезно размещать комментарии перед объявлениями некоторых методов.
- Избегайте очевидных комментариев
- Помните, что вводящие в заблуждение комментарии хуже, чем их полное отсутствие.
- Не помещайте в комментарии информацию, которая может устареть.
- Избегайте заключать комментарии в рамки, нарисованные звездочками или другим специальным шрифтом(выше упомянул //++ и //-- в комментах, не зря мне это не нравится).
Для комментариев указаны к использованию символы {} и //(/*...*/ считается устаревшим в Object Pascal).
У Тейксейры и Пачеко все листинги кода снабжены комментариями в коде, особенно для длинных процедур, красиво и аккуратно, и все понятно. В демо-примерах Delphi 11 комментов немного, по делу, но там и процедуры короткие и так все понятно из названия и по функционалу.
В принципе, то же самое, что и у нас в стандартах разработки 1С.
Все примеры притянуты за ушли, типичный говнокод.
А тут жидкая хайп тема ради холивара.
Использовать или не использовать комментарии в коде 1С - решать вам.
Юра, все просто, ты еще юн и нашел тему пиара, молодец.
Первое, использовать или нет, решать не нам, а правилам внутри проекта, команды.
А второе, видимо ты еще не попадал в серьезные команды , где ты выходишь из зоны комфорта , где начинают не спрашивать, а объяснять что есть правила и им нужно следовать.
А комментарии писать не нужно, нужно писать документацию к своим методам. Для того что бы другие поняли.
Ставлю минус , статья не о чем.
правильно документировать функции или процедуры (как в типовых) - по документации появляется подсказка применения параметров... а "включил/выключил" - это полная ересь...
// Данный фрагмент построен конструктором.", на другие комментарии смотрю лояльно - они хотя бы не раздражают.
1. Что касается Git и прочего - на данный момент считаю, что код и комментарии к нему должны быть неразрывны - и не должны находиться в разных системах. Проблемы нахождения в разных системах, думаю, можете придумать сами, если ещё не столкнулись...
Иногда пишу более подробные комментарии в процессе разработки какого-то большого функционала, чисто для себя. Потом, в процессе рефакторинга - удаляю. Но, номер задачи из трекера есть всегда.
Использование git наверное хорошо, и может быть даже правильно, но мне с ERP не зашло (слишком долго и муторно), а может просто не умею его готовить.
Имхо: комментарии в коде обязательно нужны, но те, что описывают бизнес-логику, например, почему ТЗ сортируем именно по полю1, а не по полю2, т. к. по коду и ежу понятно, что сортируем, но не понятно, почему именно по конкретному столбцу.
Разумеется, я не про писательские таланты, а про смысл.
1.
//Передача параметров "по-месту, через "?"", а не по имени, т.к.
//передача по имени, по-крайней мере в текущей верcии, не работает
Причина - потеряно 2 часа времени на поиски почему не работает передача параметров в ADO по имени.
Решения найдено не было, а первое, что придет в голову, так это передавать параметры, как раз по имени.
Тут не указан вид и версия клиента и самого MS SQL, но это излишне - если пойти на принцип, то все это
надо добывать в тек. состоянии, а не на дату комментария.
Сразу понятно, что вот не вышло и, если у вас нет веских причин, лучше не бороться с ветряной мельницей.
2.
//Да, неверно не учитывать возвраты по заказу при расчете мотивации, но таково распоряжение (заявка 0126789 от 30.03.2022)
//Чтобы вернуться к верному варианту достаточно убрать в запросе "ИЛИ ЛОЖЬ" см. текст ниже.
Без этого комментария сначала два раза правили запрос на "правильный" и потом разбирались с жалобами и стонами.
А через 3-и месяца спохватились ибо пошла "оптимизация" от менеджеров и велели сделать "правильно", благодаря этому примечанию и "мертвому коду в тексте запроса" все починили за 5 минут (Не 20с, т.к. все же надо проверять, что ты включаешь обратно).
Комментарий, казалось бы, после этого надо убрать, но буквально через 5 дней наличие оного позволило сэкономить кучу времени при разборках.
Я могу придумать способ обойтись без комментариев в обоих случаях, но не могу придумать ни одного, который был бы удобней и быстрее.
Например, второй случай реализуем с помощью коммитов в GIT и созданием (а без этого кто будет читать коммент в GIT для "точно неправильного запроcа" ?) unit теста, шоб валился и... сообщал ровно то, что было написано в комментарии.
1. Они требуются стандартами 1С (экспортные процедуры и функции)
2. Когда они требуются корпоративным регламентом (договоренности надо соблюдать, например: авторский комментарий).
Все остальное это повод задуматься: А не говнокод ли тут?
1. Комментарии - это элемент рабочего процесса программистов, работающих с кодом.
2. 1С говорит, что отлаженные модули не должны включать комментарии. "Отлаженные" - ключевое слово.
3. Если команда работает быстро и гибко, то смысл оставшегося старого кода в том, чтобы потенциальную аварию с новым кодом предотвратить. Например, есть разрабы, рефакторящие код, а есть команда, которая поддерживает оперативный контур. И вот второй команде старый код может пригодиться при очередной аварии на выкаченном релизе.
4. Авторские комментарии нужны хотя бы для того, чтобы быстро разобраться, чей это код. Да, гит и прочие фишки - штука суперская, но она далеко не у всех. Может быть в ЕДТ и есть возможность посмотреть, кто внес ошибку в код, но обычный конфигуратор потребует сравнить версию кода и версию хранилища до изменения. Часто это приводит к достаточно непростой работе поддержки по поиску виновника и попытке выяснить, с какой целью все это делалось. Авторский коммент эту проблему быстро решает.
Но да, от комментариев в дальнейшем стоит избавляться, если вы пилите коробку 1С совместимо или совместно, т.к. авторский коммент в таком коде нафиг никому из клиентов не вперся.
В общем, комментарии - это элемент процесса разработки, который при переносе кода из ветки DEV в ветку PROD должен убираться. Но комментарии, описывающие назначение интерфейсов общих модулей и модулей прикладных объектов просто обязаны присутствовать, как это сделано в БСП.
Совет про Git скоро может стать неактуальным...
Возьмут и внесут в "санкции"...
Время показало правильный выбор.
1. Авторские комментарии в целом не нужны, если это собственная разработка например или собственный объект в типовой. Когда дорабатывается типовой функционал, особенно если доработок много тут при обновлении без комментариев никак. Для сравнения\объединения каждый раз в гит лазить не будешь, объемы разработки могут быть достаточно большие, а конфигурации поставщика (для трехстороннего сравнения) может и не быть, как у нас например.. Без комментариев часть доработок будет снесена и это точно, особенно если не присутствует достаточное покрытие тестами (что еще очень очень редко бывает). Да и еще помнится совсем недавно многие использовали svn например (не в 1с), потом вот гит.. а завтра может быть какой-нибудь ruGIT или 1C сделает свое (например для форм, скд, макетов, и тд которые в xml гит вообще неудобный) и все побегут туда... коммиты из гита то же качать будем в новую систему версионирования ? Нет уж, в коде.. Номер задачи хз, специфика, если франч ну наверное надо их, если собственная команда - тут под вопросом, мы например решили что нам не надо и зафиксировали формат комментариев в соглашениях.
2. Сохранение кода - тут как вы правильно написали смотри итс, там написано нельзя, значит нельзя.. да и не зачем реально.
3. Пояснение что делает код - вот тут как бы в том же итс написано что комментарии это то что поясняет код.. сама 1с заявляет нам о том что код должен комментироваться. Конечно не стоит в комментарии повторять то что в коде написано, но те же запросы могут быть не на одну сотню строк, а еще и склеиваемые в рантайме - там комментарии обязательно я считаю, там из контекста ничего не понятно зачастую. А еще есть специфика работы, ну например есть у нас модуль с расчетом рассрочек или штрафов, он вылизан, тщательно протестирован, но иногда меняются некоторые вводные по рассрочкам, добавляются новые варианты расчета графика платежей - там без комментариев никак, то что кажется очевидным для программиста на проверку оказывается нужно делать по другому, потому что есть локально нормативные акты организации (приказы) или нормы федеральных законов которые говорят как надо, а не как логично... бывает всякая производстенная специфика, интеграции различные которые то же надо тщательно комментировать (с документацией к какому-нибудь порталу регистрации договоров в росрестре каждый раз лазить не будешь, он большой, сложный, и на каверзные вопросы отвечал лично разраб той системе в вотсапе..). А говорящие названия переменных\методов\объектов это конечно всех правильно, только 1 из 10 программистов может емко выразить сущность данных которые там будут храниться или обрабатываться. Иногда это просто невозможно.
4. Не вижу ничего плохого что бы фиксировать какой то процесс организационный в комментариях, ну например // Этот код меняется каждый месяц, может уже согласуем регламент у руководства как работает отдел маркетинга или сделаем универсально эту функцию?.. Но это скорее должно быть указано как // TODO
Вспоминаю за 15 лет работы в 1с на крупных проектах в том числе мешали ли мне когда либо комментарии в коде? Нет..
Мешало ли мне когда-нибудь недостаток комментариев что бы разобраться в сложном алгоритме в котором полно бизнес-специфики? Да.
Это очередной холивар о Чистом коде :)
От себя добавлю, что один раз открыл модуль, начал скролить его изучать и в конце меня ждала награда, голая девушка во весь рост :))) рисунок символами девушки уже тот найти не смог быстро, нашел кусочек.
Конечно это меня позабавило и я какое-то время оставлял таких же своих Котеек :) у меня даже шаблоны с ними остались.
Основная задача комментария - не вспоминать через несколько лет для чего меняли, добавляли код.
Правила Парето.
В УПП 80% исправлений, которые нужно перенести при очередном обновлении, являются несложные правками (или правками блоками), и наличие "обрамляющих" комментариев снижает время обновления до 20%.
Ну и само собой - есть такие изменения, которые очень сложно переносить и мы делаем все, что бы вынести эти изменения в отдельные блоки с минимальным остатком изменения кода в типовых модулях.
Вот например:
Я за комментарии. Но важно понимать, что комментарии как и всё в нашей жизни устаревают, и то, что было полезно во время интенсивной разработки или экстренного латания дыр, со временем превращается в те самые говенные комментарии со ссылками на всяких там уволившихся Вась, Петь.
Это не комментарии "говенные", это те, "ворочающие нос от комментариев", программисты "говенные", которые внесли изменяя в код и не позаботились внести изменения в комментарий.
ps // Если бы у меня в службе сотрудник заявил: "мне не нужны комментарии, так как мой код сам за себя говорит", то я этого сотрудника с удовольствием отправлю в бесконечный неоплачиваемый отпуск, в котором он сможет бесконечно обучать других и писать статьи на инфостарте о вреде комментирования кода.
Интересное предложение.
1. Указание автора кода и номера задачи - однозначно нужны, даже если используется GIT, просто это тупо удобно, тебе не нужно лезть в другую систему и искать коммит, по этой задаче, ты просто вбиваешь в поиск номер задачи в клиенте GIT и тебе отобразятся все коммиты. Правда не нужно при этом захламлять код старыми комментариями, их можно смело удалять, если добавил по своей в истории модуля потом можно обратно получить номера задач, blame не сильно удобен, так как код могли тупо перенести в другое место и тогда авторство сменится.
Это для тех случаев, когда работаешь с конфигуратором, если пишешь код напрямую в Visual Studio Code, то там можно и не ставить, так как при подключенном расширении git, коммит сразу отображается в тексте модуля.
2. Сохранение чужого (старого) кода - нет, так как реально вносится только путаницу, в крайнем случае, если дорабатывался типовой модуль, и вносились небольшие правки, то можно отметить комментарием, что код полностью за исключением указанных мест.
3. Пояснение того, что делает код - да, но без фанатизма, если из наименования функций итак понятно, то добавлять не нужно, а вот пояснение для чего конкретно потребовалась доработка этого модуля или процедуры или функции, и то, что не описано в изначальной задаче, я считаю нужно добавить, если это упростит поддержку решения.
4. Отражение событий в мире и организации - да, если у коллег такое же чувство юмора, как и у тебя, это может позабавить, когда читаешь чужой код, ничего страшного в этом нет.
ну и конечно же основная проблема комментариев, это поддержка их в актуальном состоянии.
Однако правила для того, чтобы их нарушать. Эта игра в комментарии или системы ведения заявок в основном плодят, чтобы было. Итогом, всё равно все колбасят, как им хочется.
Формально, у программиста рядового нет выбора. Он должен следовать регламенту, даже если он дебильный. Управленцы решают, как организовать работу. Разбор всех этих коллизий, лишних действий - проблема управленца. Пожалуйста сосредоточтесь на коде и не пишите портяночно-простынного дерьма трудночитаемого и не ленитесь осмысленно называть переменные и функции. Подумать о расширяемости и дорабатываемости вашего кода я даже не прошу. Так в корпорациях работать не принято.
Это был маленький опыт экспрессия на тему того, как я это видел на своём личном опыте.
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 1738832
Создание 05.01.23 17:30
Обновление 05.01.23 17:30
Просмотры 13676
Загрузки 0
Рейтинг
44
Комментарии 146
Код открыт Да
Рубрики Рефакторинг и качество кода
Кому Разработчик
Тип файла Нет файла
Платформа 1С:Предприятие 8
Конфигурация Универсальные
Операционная система Не имеет значения
Страна Не имеет значения
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Бесплатно (free)
