Эта страница смотрится лучше со включённым JavaScript

Комментарий для YouTube про комментарии в коде

 ·  ☕ 2 min read

Посмотрел видео-ролик от K-Syndicate Как комментарии УБИВАЮТ вашу игру, начал писать комментарий и написал чуть больше, чем хотел. Чтобы не потерять и при случае быстренько копипастить свои мысли на эту тему в другие дискуссии, продублирую его здесь.


Почти всё, что вы описали, - это проблемы “в головах” и организационные, а не комментариев, как таковых (кроме лавины комментов из плагина).

В вики описывается десяток сценариев использования комментариев, и не факт, что это полный перечень.
https://en.wikipedia.org/wiki/Comment_(computer_programming)
Народная мудрость говорит, что вместе с водой выплёскивать ребёнка не стоит. И в контексте комментирования не стоит ко всем типам комментариев относиться одинаково негативно (на последних 2 минутах ролика вы так и делаете, но общий посыл всё равно получился с перекосом в минус).
Лично я не люблю комментарии, описывающие “ЧТО делает следующая строчка кода”, это нарушение DRY-принципа; но комменты, описывающие “ЗАЧЕМ именно такой код используется”, заменить кодом гораздо костыльнее, чем написать и поддерживать комментарии (в частности, об этом вы в конце ролика говорите). В то же время, “ЧТО делает код” вполне адекватно использовать в описании публичного метода или класса целиком.

Комментарии - это набор инструментов.
“Комментарии никто не поддерживает”. Значит, эти команды программистов осознанно или нет отказываются от инструментов. Ну и зря, с таким же успехом можно и от других инструментов отказаться: от IDE, от VCS, от таск-трекеров и т.д. (некоторые так и делают, но насколько это оправданно - большой вопрос).

Туду-комменты - то же самое. Это инструмент, который вы умышленно избегаете. Как пример полезности туду-комментов: пишешь фичу, и замечаешь сложный код с потенциальным багом; разбираться здесь и сейчас - не вариант, надо фичу делать и отдавать. Ставить таск в Jira - отвлечение и смена контекста. Гораздо быстрее и логичнее оставить красный флажок и вернуться к нему в специально выделенное для этого время.

Сделайте в своей продуктовой команде “Час TODO”, например, раз в неделю, и пусть каждый программист пробегает туду-лист в IDE в полуинициативном порядке. В таск-трекере пусть это будет одна задача, а не ад микроменеджмента. Если очень хочется, к задаче можно автоматически прикреплять список коммитов, для продюсера и лида.

Ещё в Rider можно настроить вид и паттерны для кастомных туду (Settings->Editor->TODO). Так можно разделять туду для конкретного проекта, своих библиотек, чужих плагинов, своих правок в чужих плагинах, чтобы удобнее было их фильтровать, а лидам мониторить степень запущенности проекта и оценивать необходимость и объём рефакторинга.

Share on