TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
> 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:
> 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-
