Our practice is a single line in the header for every change with the date, the programmer and a brief line of description. Inline initials and date are also put where the change actually occurs:

* Form init or prg header
* 05/05/2003 TCHolzer  THISFORM.buildarray method - Added array to filter records

* in the buildarray method or in a prg where the change actually is:
*--TCH 05/05/2003 Array containing control records that should not print a form
DIMENSION contrlarry (9)
	contrlarry(1)="ARGROUP_ID"
	contrlarry(2)="CREDITMO_ID"
	contrlarry(3)="DEBITMO_ID"
	contrlarry(4)="DETAIL"
	contrlarry(5)="INVOICE_ID"
	contrlarry(6)="POLICYH_ID"
	contrlarry(7)="PROFILE"
	contrlarry(8)="RECEIPT_ID"
	contrlarry(9)="SESSION_ID"

>Renior,
>
>Good heavens! 18 lines of code to document 2 defect lines That's rather excessive. One comment block is sufficient for the two lines of code.
>
>I do believe you'll get tired of reading that same assumptions block in every method.
>
>Are the requirers exCOBOL programmers? *bg*
>
>In my humble opinion, huge comment blocks like that do more harm than good. Since they contain so much pointless garbage they aren't always kept up to date, and when someone else comes along behind the developer and finds the code out of synch with the comments, what is correct the code or the comment?
>
>I believe in documenting code, mostly done with 1 or two lines of comment right in the place in the code where it's needed.
>
>>We are being required to use this type of function comment header and defect change headers for all methods, function, programs, etc. I really don't have a problem using the change headers, but the function comment header seems incredibly superfluous for predefined methods like the Click event of a checkbox. I could see it being used for user-defined methods, but in the Foxpro predefined ones it just seems to be a waste of time. Maybe it's just the way I see it. Any thoughts on this?