>Of all the code that I have to maintain, the project I find easiest is the one where I have a very clear separation of concerns.

Agreed. I have to come into projects where there is legacy code. Sometimes the project is to replace the existing solution with the new product or to enhance the existing solution with an upgrade. Where there is clear definition of the code (in one place), it is easiest to maintain. In your case, the separation is a custom method at the form level for the commandbutton click event to respond to; in my case it is in the click method of the click event directly. In either case the separation is there; it is a matter of choice where to put it. Either is a good practice to me and works well -- the key is to have a distinct function for the method and it be self-contained.

Now if the commandbuttons are named command1, command2, etc. then finding the appropriate commandbutton and referencing it in code becomes very problematic -- what does thisform.command1.click() do (your case would be superior and preferred in this situation as the methods give the information of what is to be done)? In the case of thisform.cmdSaveObject.click() it becomes more apparent to the reader of the code what is to be performed (just as yours would be easy to also to understand; i.e. thisform.SaveObject()). To me these are programmer preferences as long as good naming practices are followed in all objects -- the only limitation I have found in VFP is the memberdata field which is limited for the camel case naming of the methods to be used in the Intellisense.

In the case of having class objects that are reused, it becomes more problematic. When the code has to be changed or enhanced (or to fix a bug) you have to consider all other places the object method is being used -- one code's bug maybe another code's feature. So it becomes more difficult to work with. You have to find all places where the code is being used, determine impacts to all places if any and then finally begin to make the changes which can subsequently cascade into other code areas because of dependencies. So in this case I find working with code in classes much more difficult and not as friendly. Again the KISS principle --- keep each method to do a specific function is the best I have found.

Yes it is true, that as a contractor I am not working with my code for long periods -- on a project today and gone tomorrow. However, the customer expects that the code I write and leave behind is understood by the in-house programmers and is documented with pseudo code and flow charts. Delivering good sound and easy to understand code is essential in this business if you want to have the customers ask for you back in future projects.

But I have to work many times with legacy code that is poorly written. Having code jump all over the place which uses many class methods (for the reuse goals) makes the code hard to understand and is typically "spaghetti" code. It takes longer on my part to understand the legacy code and then to make the appropriate changes. The customer wants us (the consultants) to do our work quickly and in a clean way - they are paying high for our services. So I am very familiar with having to inherit code and then to find the solution for the project.