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.
> Hi doxygen (and similar) users,
>
> Are any of you involved in formal code reviews to check/edit the =
> comments for embedded documentation? If so, howz that workin' for ya?
>
> We're trying to improve integration of embedded documentation within
> our =
> code base for our SDKs, along with other improvements in our code review =
> process. As the technical writer for the department, I'm trying to swim =
> further upstream in the s/w life cycle to effectively contribute to the =
> content, quality and consistency of the embedded documentation. So far, =
> it's been difficult to access the code before code-freeze to edit the =
> comments. Therefore, I want to incorporate myself into the formal =
> schedule for code reviews (as long as that happens for the projects... =
> <smirk>).
Check the archives for last week's discussion of "Code comments as
Documentation".
Being involved in code reviews is good, but you need to swim further
upstream and get at least read access to the source control
system---read-write access is far preferable.
If you can check out but not check in, you can at least run Doxygen on the
code base, and file bugs for both Doxygen syntax errors and content
errors/omissions. When the programmers get tired of seeing your doc-related
bugs, they can give you write access to go fix them yourself. Learn to use
the development tools so that you can run the same build and test procedures
as the programmers do when they check in code changes.
Give your programmers a "template" for what needs to be documented for each
function, class, etc. That includes both what Doxygen tags are required and
what content questions must be answered. The article "How to Write Comments
for the Javadoc Tool" (http://java.sun.com/j2se/javadoc/writingdoccomments/)
is a good resource, regardless of what tool you're using. At a previous job,
I boiled this article down to a 2-page tipsheet. Ideally, get this included
as part of the team's coding conventions.
With this preparation, after a few rounds of code reviews in which you nag
the programmers to follow the doc comment standards, they should start to
follow them just to avoid being hassled. Then you will be able to actually
add value by asking substantive questions in code reviews.
-------------------------
Janet Swisher
Senior Technical Writer
Enthought, Inc.
1-512-536-1057
ROBOHELP X5: Featuring Word 2003 support, Content Management, Multi-Author
support, PDF and XML support and much more!
TRY IT TODAY at http://www.macromedia.com/go/techwrl
WEBWORKS FINALDRAFT: New! Document review system for Word and FrameMaker
authors. Automatic browser-based drafts with unlimited reviewers. Full
online discussions -- no Web server needed! http://www.webworks.com/techwr-l
---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- techwr-l -dot- com
Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit http://www.techwr-l.com/techwhirl/ for more resources and info.
