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) но во внутреннем, скрытом репозитории кода, а в открытом – версия без комментов, т.к. возможно именно комменты и описание алгоритмов поверх открытого исходного кода, они воспринимают как интеллектуальную собственность, и поэтому не публикуется?

★★★★★

Зависит от размера проекта и его назначения. Если это что-то торчащее наружу с чем будут работать люди, то надо 1, 2, и иногда и 3, если есть что-то не стандартное.

peregrine ★★★★★
()

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

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

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

Этого абсолютно недостаточно. Нужно еще указывать какой алгоритм (если не тривиальное что-то) и почему использован, хорошим тоном будет даже ссылка на книгу и номер страницы и/или сайт в интернете с описанием. Если алгоритм самим разработан, то на базе каких и краткое описание как он работает.

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

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

Документировать же все в наименованиях и невозможно в принципе и слишком длинные наименования могут даже затруднить понимание. Если реализованы какие-то математчиеские формулы чаще проще видеть одно-двух-буквенные имена переменных + ссылка на алгоритм или его описание прямо тут же, чем трудолюбиво выписанные многословные названия.

Ну и собственно сам же и ответил на вопрос

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

Иначе и быть не могло. А то, что в некоторых проектах комментариев нет еще вопрос почему: не было изначально (и тогда это очень плохо для проекта) или нарочно удалены перед выкладыванием.

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

praseodim ★★★★★
()
Последнее исправление: praseodim (всего исправлений: 1)
Ответ на: комментарий от praseodim

Вообще я даже скажу, что для свободы программирования, хорошая документация может быть даже важнее

Хорошая мысль, согласен.

или нарочно удалены перед выкладыванием.

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

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

Ну и вот - короче открытй код не ради так сказать идей Столлмена, а ради какой-то выгоды, но соответственно остаётся ощущение интеллектуальной собственности и комменты всякие бережно затирают.

Есть такая мысль у меня:)

bonta ★★★★★
() автор топика

дополняю функционалом некоторый проект

функционалом

Пишешь софт для математиков?

DELIRIUM ☆☆☆☆☆
()

Вы путаете документацию с комментариями. Документация нужна, комментарии - нет.

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

функционал
DELIRIUM
для математиков

От тебя ожидалось другое определение этого термина (2)

TheAnonymous ★★★★★
()

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

Я личто не пишу комментарии на функции в своих проектах, но часто комментрирую алгоритмы и ветки if.

shimshimshim
()

Покажи минимальный пример доксигенских комментариев (в теге code соответствующим синтаксисом и оформлением), которого будет более чем достаточно для описания метода.

deep-purple ★★★★★
()

Делаем как люди которым ты благодарен и всех кого можем пинаем делать так же.

pon4ik ★★★★★
()

Комментарии встречаются, например, хотя и мало, в коде Хромиума.

Комментариев (дофига) есть в коде markdown-it (лучший на сегодняшний парсер Маркдауна, созданный Vit, и включенный, как минимум, в дефолтную поставу Visual Studio Code).

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

Deleted
()
Ответ на: комментарий от pon4ik

Покажи минимальный пример доксигенских комментариев (в теге code соответствующим синтаксисом и оформлением), которого будет более чем достаточно для описания метода.

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

З.Ы.: Вимрц у тебя дюже навороченый, я таким кол-вом плагинов не пользуюсь (кстати, один какой-то не установился). Свой вимрц сейчас не покажу — с собой нету и никуда не выкладывал.

deep-purple ★★★★★
()

но над Блинком и Телеграмом, ведь трудятся огромное кол-во людей…

Тдесктоп написан одним человеком.

gadfly ★★
()

Доксиген — документация в коде, а не комментарии. Документация нужна, комментарии — нет. </thread>

Moondancer
()
Ответ на: комментарий от deep-purple

В вимрц помойка да, но этот конфиг уже родной на уровне моторных навыков. Иногда чищу, под весеннее обострение его :)

Инглишь корявенький, лет 7 ибо сему кодику:

 //! Lookups timezone object for future usage in corresponding api.
    //! Timezone object must be freed with dt_timezone_cleanup() function on successful operation
    /*!
     * \param timezone_name name of timezone for lookup, it can be in olsen database format, or in windows standard time format
     * \param timezone [IN/OUT]pointer to timezone object
     * \return Result status of the operation
     * \sa dt_timezone_cleanup
     */
LIBDT_EXPORT dt_status_t dt_timezone_lookup(const char *timezone_name, dt_timezone_t *timezone);

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

Спасибо!

А доксиген можно настроить так, чтобы токен «//!» воспринимался как часть документации, а «///» — нет? Ато я из того что вычитал, понял, что он жрёт всегда все какие может. Я просто хочу чётко разграничить синтаксис доксикомментов и обычных комментов.

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

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

С таким байтодрочем надо по-любому разбирать всё поэтапно, представлять в голове, рисовать что-то; комментарии тут мало чем помогут, если ещё больше не запутают.

Moondancer
()
Ответ на: комментарий от deep-purple

Доксиген не единственный вариант, был ещё как минимум phoenix или как то так. Хотя дефолт для крестов конечно doxygen. Жрёт он свои комменты вроде все всегда. Сгенерируй конфиг доксигена, там будут все параметры с комментариями. Их не так уж и много, можно просто прочитать все.

pon4ik ★★★★★
()

Ведете ли I,II

Да, всегда. Иначе сам потом будешь голову ломать, «почему так».

Неужели им не мешает отстуствие комментов в коде

Они их не удаляют ли, перед публикацией кода? Сильно сомневаюсь, что можно писать вообще без комментариев.

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

Вот не скажи. Если тебе человек написал что сей мега ксорорксор заменяет такую то ветку if'ов из референса - он сэкономил тебе кучу времени, либо ты любишь байты регулярно и круглосуточно.

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

Вот потому что доксик есть дефолт, то я с ним и решил помучаться. Жаль что жрёт все подряд. Конфиг, конечно, ковыряю.

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

комментарии тут мало чем помогут, если ещё больше не запутают

Капитанские комментарии, да. Нормальные комментарии это заметки на тему кода. Т.е. они должны объяснять почему-зачем, а не как.

no-such-file ★★★★★
()
Последнее исправление: no-such-file (всего исправлений: 1)
Ответ на: комментарий от pon4ik

Вот почему у меня в виме чисто (ну кроме табов и сплитов) — каждая задача в своем терминале открыта. В одном вим, в другом гит, в третьем сборка, в четвертом запуск и дебаг. Переключаюсь на них по Alt+Tab (удерживая Alt дальше можно только стрелками) средствами DE/WM, плюс воркспейсы/десктопы по Ctrl+Alt+стрелки на прочие браузеры и файломанагеры.

deep-purple ★★★★★
()
Последнее исправление: deep-purple (всего исправлений: 2)
Ответ на: комментарий от deep-purple

Ну, это на любителя. Я не люблю полагаться на ДЕ, как минимум потому, что время от времени переключаюсь между ними. А когда у тебя всё в терминале, а трудишься ты на сервере - тебе практически пофиг что тебе рисует gui, главное что бы шрифты были не отвратные(привет putty). Ну и tmux - сессия рабочая живёт до сбоя по питанию.

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

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

Qt таки использует doxygen. Правда они его выхлоп потом постобрабатывают ещё.

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

Вот, например.

/** 
  * @brief Write put area to PhysFS file. 
  * @param c Extra character to add to buffer contents. 
  * @return Non-EOF on success, EOF on failure. 
  */ 
virtual int_type overflow(int_type c = traits_type::eof()) override;
У меня комментарии для doxygen в таком стиле.

Meyer ★★★★★
()
Последнее исправление: Meyer (всего исправлений: 1)

Всегда пишу комментарии для публичных методов (как Java-разработчик). Иногда пишу для непубличных, если сам возвращаюсь и долго не могу вспомнить, почему именно к такому решению я пришёл когда-то.

У нас в компании официально документацию пишем на все публичные (отсутствие как ошибка, ловится SonarQube и maven-checkstyle), но в действительности в коде часто можно увидеть NOSONAR.

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

Deleted
()
Последнее исправление: merhalak (всего исправлений: 1)
Ответ на: комментарий от Deleted

SonarQube

Чего ещё он полезного делает? Кто его конфигуряет? Сложно ли это? Куда чаще всего в нём вы смотрите?

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

Я его не конфигурирую. Увы, его настроили лет 10 назад и благополучно забыли.

Лично я туда заглядываю в 2-х случаях: какие классы слишком большие и их неплохо было бы зарефакторить, где забыл документацию доложить (бывает). Ну и всякой фигни, по мелочи. Эта штука на меня практически не ругается (технический долг в 8 часов, и то потому, что есть классы с большим количеством методов в паблике и проверка на использование потоков в JavaEE 2, которая неактуальна в Swing приложении).

А обычно он ругается на e.printStackTrace(), который очень любят у меня в команде, забытые комментарии в документации, несоответствие формата кода стандарту в предприятии. Но со мной такое случается слишком редко, чтобы я на это вообще обращал внимание.

Deleted
()
Ответ на: комментарий от pon4ik

Аргументированно. Когда я начну что-то ковырять удаленно — вспомню твои доводы.

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

У тебя так (ат). А у других? Это я в смысле я бы посмотрел на реальный эталон от которого не плюются другие, который действительно уровнем продакшн и всё в таком духе, а не самобытный выбор. Только не скидывай копипасту из публичных мест типа документации кутей (публично я и так увижу). Скинь пример из энтерпрайзного проекта в котором у вас всё по полочкам разложено и серьёзная работа налажена.

deep-purple ★★★★★
()
Последнее исправление: deep-purple (всего исправлений: 1)
Ответ на: комментарий от Deleted

Окак, звучит прикольно, жалко, что с плюсами там нужны танцы.

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

А мне вот твой пример понравился. Самое главное, действительно, наличие восклицательного знака и обратных слешей однозначно определяет для чего этот текст.

deep-purple ★★★★★
()

Я как-то работал в конторе, в которой документировать обязаны были *КАЖДУЮ* сущность, включая константы. И код там был в духе

enum my_cool_stuff {
    MY_COOL_ELEM_1 /// This is MY_COOL_ELEM_1
};

/// \brief Put a session.
/// \param session - Session to put.
/// \return Nothing.
///
/// Put a reference to a session. If ref_cnt is zero session is destroyed.
///
void foobar_put_session(const struct session *session);

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

Так что даже не знаю, если честно.

kirk_johnson ★☆
()
Последнее исправление: kirk_johnson (всего исправлений: 3)
Ответ на: комментарий от pon4ik

либо ты любишь байты регулярно и круглосуточно

А иначе зачем вообще лезть в байтодроч? Сломаешь всё гарантированно, если не понимаешь, как байтодроч в принципе работает.

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

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

Во-вторых, «почему-зачем» зачастую размазано не то что по разным блокам кода, а и вовсе по разным модулям. Комментировать такое в одном месте — бессмысленно, копипастить — тоже; для видения полной картины нужно учитывать логические связи, которые не покрываются взаимодействием кода (ибо с технической стороны ничего не значат и даже на ООП-модель не ложатся), но являются частью бизнес-логики. Лучшее место для такого — сопроводительная документация, отдельная от кода, а вот с самим кодом беда. Когда-то для такого аж придумали аспектно-ориентированное программирование, но оно толком не взлетело, оставив по себе в мейнстримных языках разве что декораторы.

Moondancer
()
Ответ на: комментарий от deep-purple

Ахтунг! В дикой природе обнаружен живой экземпляр вимера-стрелочковоза! Ловите за уши, или за жопу, пока не убежал, его срочно нужно отправить в поликлинику для опытов!

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

Изврат — это твои аскии картинки на лоре из шрифтов брайля.

А в комментариях нарисовать палочками квадратики и стрелочки — нормальная практика (даже в спеках RFC всяких такое часто есть).

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