My rule for documentation is that I should be able to look over the code in a few years and see easily what the code does and whether all or parts of it is useful to any task at hand.
This leads me to a style similar to that of documenting new projects in sections:
For documention of individual functions that aren't completely obvious, I tend to add a couple lines of comments to indicate algorithms or other unusual behavior. With good variable names, this isn't needed much. An example:
# Generic job monitor for watching jobs finish.
# - No action is taken when each job finishes.
# - Function returns when all jobs have finished.
# - Inputs: A hash of job IDs from LSF
# - Returns: No specified return code
One thing I try to remember is that while things may seem obvious while writing and testing the code, a year or so in the future they won't be. Commenting with that in mind has helped me out in many situations.
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.
| & || & |
| < || < |
| > || > |
| [ || [ |
| ] || ] ||