in reply to
Preferred method of documentation?
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.