RE: Code comments extraction for documentation

Subject: RE: Code comments extraction for documentation
From: "Matt Horn" <mhorn -at- adobe -dot- com>
To: "John Harrington" <beartiger -at- gmail -dot- com>, <techwr-l -at- lists -dot- techwr-l -dot- com>
Date: Tue, 24 Oct 2006 07:13:12 -0700

> By "comments extraction", I mean extracting comments from code (e.g.,
> c++) for use in documentation (e.g., of a software developers' kit).
> If there is a more standard name for this, please let me know.

I just call them code documentation tools. You can use them to generate
primarily online doc for class libraries. This doc can show class
hierarchies, plus all the method-level details like param types, return
types, etc, and other stuff like exceptions, constants, etc. Having them
all cross-linked is a huge win for our users. We also use these tools to
insert running code examples into the output. We also have a system in
place that lets us cross-link the code doc output with the traditional
"usage" docs and vice versa. Another big win for users.

> Has anyone on the list tackled the problem of comments
> extraction in a documentation project?

We do it for Java and ActionScript class libraries.

> 1) What tool(s) did you use/recommend? Or did you roll your own?

For Java class libraries, we use Javadoc. For ActionScript libraries, we
rolled our own tool called ASDoc which is modeled after Javadoc.

You can see what the ASDoc output looks like here:

http://livedocs.macromedia.com/flex/2/langref/index.html

> 2) What are some other leading tools you know about and why
> did you prefer the solution you used?

Javadoc is the standard for Java class libraries. We came up with our
own solution for ActionScript because we wanted to add some features
that existing tools did not offer. The ASDoc tool is now a feature of
the product, too, because so many users were asking for it.

> 3) How did you deal with editorial review and updates to content?

It was initially a bit of a problem because of the sheer volume of doc
generated by ASDoc. So, initially, it required some major passes through
the generated output by doc, editorial, and engineering. Now, we just
file bugs against errors in the documentation, just as anyone would file
a bug against a class or feature.

Writers make edits to the source code (ie, the *.java or *.as files). We
run local builds before checking anything back into the source tree,
because syntax errors in comments can cause builds to break just as
other types of errors do. And we hate breaking builds. That's the
engineer's job. :)

hth,

Matthew J. Horn
Sr. Technical Writer
Adobe Systems, Inc.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

WebWorks ePublisher Pro for Word features support for every major Help
format plus PDF, HTML and more. Flexible, precise, and efficient content
delivery. Try it today! http://www.webworks.com/techwr-l

Easily create HTML or Microsoft Word content and convert to any popular Help file format or printed documentation. Learn more at http://www.DocToHelp.com/TechwrlList

---
You are currently subscribed to TECHWR-L as archive -at- infoinfocus -dot- com -dot-

To unsubscribe send a blank email to
techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit http://lists.techwr-l.com/mailman/options/techwr-l/archive%40infoinfocus.com


To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit
http://www.techwr-l.com/techwhirl/ for more resources and info.


References:
Code comments extraction for documentation: From: John Harrington

Previous by Author: RE: Chapter summaries at start of doc: yes/no?
Next by Author: Re: If you don't want people to know your age...
Previous by Thread: Code comments extraction for documentation
Next by Thread: Re: Code comments extraction for documentation


What this post helpful? Share it with friends and colleagues:


Sponsored Ads