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.