>Thank you, George

You're welcome, Joe.

>I follow most them except for the Exit. Sometimes I DO WHILE .T. something, then jump out when some condition is satisfied.

To me DO WHILE .T. isn't readable because .T. never is equal to .F. More likely, I'll set a variable (like lldone) to .F., then at some point something lldone = (onevalue = another) or something similar. Another is DO WHILE lni < lnlast, and/or compound conditions: DO WHILE NOT lldone AND lni < lnlast

>What do you mean by 9. and 10. ?

Cohesion describes how reliant a procedure/function or object is on things outside itself. With procedures and functions, the values that are necessary should be passed through the parameter list. An object is a bit different. The example I like to use is one involving a command button that brings up a GETFILE() or PUTFILE() dialog. If the command button also has to update the value of a textbox with the filename, then it is "tightly coupled" to the textbox and can't be used with a label to hold the value. However, if it were designed with a visible filename property, and assigned it to that, followed by This.Parent.Refresh, the Refresh event of the parent object would then be responsible for updating the text box. Such a command button then could be re-used wherever desired.

Proving algorithms is an essential phase of the design process. If an algorithm is proved to work everytime it called, then it's proven. Can we possibly test for all possible conditions, No. However, we can use proof by mathematical induction where it isn't possible to check all possible conditions. Basically, this involves a sampling of a combination possible values to prove that the algorith works.