LINUX.ORG.RU
ФорумTalks

Документирование кода

 ,


0

1

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

    /++ Background colors +/
    enum Background {
        transparent,  /// Transparent
        light,  /// Light background
        dark,  /// Dark background
        action   /// Background for actions
    }
ну тут же и так все очевидно и понятно, но чтобы автогенератор понял что нужно описать этот enum и добавить в документацию, приходится вот такое вот писать.
Еще вопрос - стоит ли писать коментарии к override методам?
Ну и конечно же комментарии удобны тем, что можно быстро получить хелп по данному методу.
Но если же лучше писать внешную документацию вручную, то как лушче всего ее поддерживать в актуальном состоянии?

★★★

 transparent,  /// Transparent
 light,  /// Light 
 dark,  /// Dark 

О. Узнаю себя

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

Коментарии нужны для объяснения контекста, который шире экрана с кодом, на который смотришь. Коментарии как в твоем примере не нужны.

xnick
()

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

mm3 ★★★
()

У doxygen есть опция документировать все скопом, даже те структуры, на которые не расставлены комментарии.

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