I was always told in my early career to always document things that the readable (hopefully) code didn't tell you and to make the code legible i.e. comments like
* Increment the counter nCounter=nCounter+1 are really superfluous if the variables are declared with sensible names and merely clutter up the coding. What is good however is to document all procedures/subroutines/classes etc with a description and the parameters i.e 1. Brief Description of the process 2. What goes in 3. What comes out 4. Any potential problems that have not been addressed. It goes without saying that all modification dates, descriptions and author information should be present in a system along with some form of timeline as to the modifications etc. There is nothing worse than verbal diarrhoea when it comes to documentation, un less of course the "nothing" is a total absence of comments with deliberately vague variable names! Dave _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[email protected] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
