I recently did some work on an Excel TDD harness (here), and I found it very useful to take some code that was not well documented and write documentation for it, both technical and user. I have often heard that documentation is better when written by someone other than the original programmer, and there are comments in this thread about how poor some of the documentation is. By following this approach, a number of benefits are available, if the module is being maintained. First and most obviously, the community benefits from the documentation. Second, if I were the author of anything on CPAN, I would respond much more favourably to someone who wrote "I'm trying to improve the documentation. Have I understood this properly?" (especially if shown draft documentation) than to "I'm a beginner and don't understand". Third, the code is getting a review that might identify bugs. Even if they aren't fixed, it is useful to have them documented.
Regards,
John Davies
-
Are you posting in the right place? Check out Where do I post X? to know for sure.
-
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big>
<blockquote> <br /> <dd>
<dl> <dt> <em> <font>
<h1> <h2> <h3> <h4>
<h5> <h6> <hr /> <i>
<li> <nbsp> <ol> <p>
<small> <strike> <strong>
<sub> <sup> <table>
<td> <th> <tr> <tt>
<u> <ul>
-
Snippets of code should be wrapped in
<code> tags not
<pre> tags. In fact, <pre>
tags should generally be avoided. If they must
be used, extreme care should be
taken to ensure that their contents do not
have long lines (<70 chars), in order to prevent
horizontal scrolling (and possible janitor
intervention).
-
Want more info? How to link
or How to display code and escape characters
are good places to start.
|
