public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: rthorpe@realworldtech.com
To: gcc@gcc.gnu.org
Subject: Use of automatically generated docs (Doxygen) experience from another project
Date: Wed, 28 Jan 2004 14:20:00 -0000	[thread overview]
Message-ID: <218280-220041328141940810@realworldtech.com> (raw)

I recently retrofitted Doxygen documentation onto a program.  It was
much smaller than gcc, but I can tell you what I found.  If your not
interested in the experiences of a random lurker stop reading now.

I found:

Comment obfustication

Doxygen markup need not disrupt the comments, if you use it
selectively.  I ignored @param and @return, I only used /** and @file
at the top of files.
Avoiding @param and @return doesn't make it much less useful either.
It would take years to annotate gcc's comments with @param and
@return anyway.

Documentation usefulness

I didn't find the generated docs very useful.
The reasons are:

1) Function and variable comments aren't really as useful as Emacs M-.

2) The docs extracted from the comments heading the files describing
them turned out to be the most useful.  But they were often too
detailed or too simple (or both).  So when I needed to describe the
high level design of the program I wrote a separate document.

3) Lists of functions aren't as useful as header files (but in my
case the header files were very clear).

3) Doxygen is very C++ orientated.  Also, in C++ there are many more
types of things, so doing much more classification is appropriate.

4) Quite often you get a really puzzling piece of Doxygen output with
too much info on it to understand.

Strangely enough the most useful thing was looking at which functions
called which others, that gave me a better idea of where modules were
too highly coupled.


                 reply	other threads:[~2004-01-28 14:19 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=218280-220041328141940810@realworldtech.com \
    --to=rthorpe@realworldtech.com \
    --cc=gcc@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).