Re: Code Comments, Code Reviews and Tech Writers

Subject: Re: Code Comments, Code Reviews and Tech Writers
From: "Janet Swisher" <swisher -at- enthought -dot- com>
To: "TECHWR-L" <techwr-l -at- lists -dot- techwr-l -dot- com>
Date: Wed, 6 Oct 2004 10:36:58 -0500

"Dave Neufeld" <Dave_Neufeld -at- spectrumsignal -dot- com> wrote:

> 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

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" (
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.


ROBOHELP X5: Featuring Word 2003 support, Content Management, Multi-Author
support, PDF and XML support and much more!

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!

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 for more resources and info.

Previous by Author: Re: I need a user-friendly term
Next by Author: Re: Telecommuting/offshoring
Previous by Thread: Re: Code Comments, Code Reviews and Tech Writers
Next by Thread: Re: Code Comments, Code Reviews and Tech Writers

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

Sponsored Ads