LINUX.ORG.RU
ФорумTalks

Про комментарии в исходном коде

 ,


0

2

Предварая темку, хочу сказать что фактически я занимаюсь чем-то типа аутсора на дому, т.е. это и не фриланс, где, наверное, для заказчика продукт это действительно черный ящик со входами и выходами – в аутсорсе же твой продукт проверяется работодателем как именно проект (архитектура, алгоритмы, код), но тем не менее это не есть плотное взаимодействие с коллективом… Т.е. «вращайся» бы я в каком-нибудь коллективе очно – может быть таких вопросов и не было :)

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

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

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

Но как я оказался благодарен прошлым разработчика за то, что:

I. Буквально каждый метод любых интерфейсных классов продокументирован (в стиле доксиген).

II. В каких-то алгоритмических штуках (там всякие графы и алгоритмы поиска) важные места кратко описаны в комментариях непосредственно в коде.

III. К проекту есть описательная документация (т.е. такая общая – например, как работают алгоритмы в общем, без привязки к деталям реализации).

Все эти три пункта делают хороший вклад и в ориентировании в коде, и в видении архитектуры продукта и т.п. Без любого из этих пунктов тратилось бы намного больше времени чтобы разобраться. При этом пункты 1, 2 так вообще кажется не потратят много времени на своё сопровождение от разработчика. Да, если в методах много параметров, и много методов с документацией_доксиген этих параметров, и бывает что параметры меняются, и отвлекаться когда «прёт» на отражение изменений в комменты_документации не хочется – ну и пусть. Ведь можно же выделить скажем раз в неделю, в пятницу вечером, время на приведение этих комментов к новым изменениям (исключительно в своей зоне ответственности). А пункт 3 конечно тяжелый, но мне кажется, если это не проект на просто «раз-два и в продакшн» - то для самого себя же возможно пригодится, если случится вернуться к проекту спустя годы…

И вот например в проектах, которые такие доолгие, как колекция компиляторов GCC (по крайней мере STL ++ либа), как ядро Линукса - всё очень хорошо с комментариями.

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

А вот взять не такие дооолгие проекты – Телеграмм, движок Блинк, какие-нить простенькие игры которые по умолчанию в дистрибутивах включаются – в их коде нет комментов. Ладно Xmoto, но над Блинком и Телеграмом, ведь трудятся огромное кол-во людей… Неужели им не мешает отстуствие комментов в коде?

В общем интересно что Вы думаете про комментарии в коде.

1. Ведете ли I,II (а может III) в своих личных проектах?

2. В «корпоративных» проектах – как у вашей компании принято на тему I, II, III – т.е. доксиген_комментариям_к_параметрам_фии_и_её_предназначения(I), комментам_внутри_тела_ф-ии(II), отдельного_описания_логики(III). Может быть у вас даже принято UML схемы составлять и прицеплять их в (III). Расскажите, пожалуйста, очень интересно.

3. Что думаете на тему Блинка, Телеграмма, и прочих больших проектов, код которых открыт – почему там нет комментов? Может быть там все это есть (I,II) но во внутреннем, скрытом репозитории кода, а в открытом – версия без комментов, т.к. возможно именно комменты и описание алгоритмов поверх открытого исходного кода, они воспринимают как интеллектуальную собственность, и поэтому не публикуется?

★★★★★

И вот, сейчас дополняю функционалом некоторый проект.

чем ты там занимаешься, говоришь?

system-root ★★★★★
()
Ответ на: комментарий от Moondancer

комментарии должны быть правдивыми и актуальными

Ага, а ещё не должно быть бедности, болезней и смерти. В идеальном мире. Комментарии это просто заметки «на полях», они такие же «несовершенные» как и код, что бы там ни писали в умных книжках.

выразил это в комментарии, в коде написал реально другое

Комментарии пишутся _после_ написания кода.

Лучшее место для такого — сопроводительная документация

Это худшее место. Комментарии я пишу сразу после кода, пока я ещё «в теме» и имею свежие впечатления от решения. А когда я там доберусь до написания документации... через месяц (или никогда, что вероятнее).

no-such-file ★★★★★
()
Ответ на: комментарий от deep-purple

Я люблю @ и сишный стиль комментов. Алсо ядерный формат и то, что в хаскеле сделано, я до сих пор считаю самым адекватным из всей плеяды доки-из-кода.

kirk_johnson ★☆
()

Комментарии не нужны!

I. Буквально каждый метод любых интерфейсных классов продокументирован (в стиле доксиген).

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

II. В каких-то алгоритмических штуках (там всякие графы и алгоритмы поиска) важные места кратко описаны в комментариях непосредственно в коде.

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

III. К проекту есть описательная документация (т.е. такая общая – например, как работают алгоритмы в общем, без привязки к деталям реализации).

Нужно, потому как надо как-то новых девелоперов вводить в курс дела, иначе придется тоже самое объяснять устно. Без общего описания проекта часто бывает, что совсем не понятно что там происходит, особенно если его разработчиков в компании не осталось.

Подводя итоги: комментарии не нужны! Это я говорил начинающим разработчикам которые свой путанный код пытались спасти комментариями, но эти комментарии совершенно не помогал разобраться в том как в их код внести маленькое изменение ничего не поломав. Хотя тут уже спасало обязательное требование писать юнит тесты, только доверия к тестам тоже особо не было, все ли возможные состояния покрывает этот тест было непонятно.

Aber ★★★★★
()
Ответ на: комментарий от no-such-file

они такие же «несовершенные» как и код

Ну и смысл две взрывоопасные штуки рядом класть?

Комментарии пишутся _после_ написания кода.

Как это меняет описанную ситуацию? Разработчик опишет то, что думал, а бага в написанном коде так и не заметит.

Комментарии я пишу сразу после кода, пока я ещё «в теме» и имею свежие впечатления от решения

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

Moondancer
()
Ответ на: комментарий от no-such-file

комментарии должны быть правдивыми и актуальными

Ага, а ещё не должно быть бедности, болезней и смерти. В идеальном мире. Комментарии это просто заметки «на полях», они такие же «несовершенные» как и код, что бы там ни писали в умных книжках.

+1.

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

Если это библиотека то комментарий нужен! Он первичен, а если функция работает не так как написано в комментарии, то это баг в функции. Потому, что контракт у библиотеки не должен меняться.

Aber ★★★★★
()
Ответ на: комментарий от Moondancer

Разработчик опишет то, что думал, а бага в написанном коде так и не заметит

И каким боком это относится к комментированию?

высирает по-другому

Это проблема тимлида, который должен был рассказать джуну как надо, посмотреть результат и т.д. Джун и с полным описанием по книжке может слепить какаху.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

И каким боком это относится к комментированию?

Тем, что оно запутывает. Без комментариев приходится смотреть на реальную реализацию.

Это проблема тимлида

А если и сам тимлид не знает, потому что команда за время жизни проекта сменилась? Со всезнающим тимлидом комментарии тоже не нужны :3

Moondancer
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.