>>In the example you gave, I would have a form-level Save method, called from the button's Click, from the Save item on the menu, from the Save button on the toolbar and anywhere else that Save is the appropriate operation. I think that's much easier to understand for the person taking over the code and much easier to maintain as things change.
>
>To me it is easier to understand that the 'Save' button does the work of the save operations for the form -- I don't have to go elsewhere to search for the methods. In your way of programming, each button would have to call another custom defined method; so for a form with 20 buttons that each do a specific function, you would have twenty custom methods defined at the form level (one for each button). In my approach, each button's click method contains the code for the unique operation -- only one place to look. So a new programmer who first looks at my form and wants to know what the save method is would first look at the save commandbutton click method and see the code; in your solution, the same programmer would go to the same commandbutton click method and then find a reference to another method -- now they would have to navigate to this code (more steps to get to the same save code).
>
>In the case of Craig Berntson, now you have to go to another class object to get to the save code. Now any changes have to be carefully considered for impacts to other places that use the class code -- so you now have to perform a search to determine where else it is used and how it is used. Much more effort is needed by the new programmer to understand the whole usage of the class object method before any change can be made. The save method is not confined to the single usage in the current form but can be used by many forms. To me, sometimes we programmers "kill" ourselves with bugs that are introduced in class object reuse in the name of quicker coding.
>
>To me it is a matter of programmer preference -- I don't believe either style of programming is "more" correct than the other. I typically reserve custom methods to be methods that are called in different places and have passed parameters and a return value. Each of these methods are designed for a specific purpose and are self contained. Another use of custom methods is when there are large code blocks that are repeated in a single method or where recursion is needed. But these are my preferences.
>
>I work as consultant programmer and have to develop code for many customers in large ERP solutions. All my customers have indicated that my coding practices are easy to understand and follow. In none of my code reviews has a customer complained of how my methods are defined. I have for the past 15 years worked in this environment where my code development will be inherited by another programmer -- I am only at a customer site for a project duration and then I leave. In house programmers then have to manage my code for continued changes based on new business requirements or future upgrade projects. Going from one method to another method and then to another class method is not always the best solution for ease of understanding -- typically I have found that this complicates the code. Additionally, the in house programmer is uncertain of any changes that might impact other places that the code would be used if it is a reuse class object and referenced in many places. Having confined code makes the job easier -- a lesson to learn is to "Keep It Simple - Stupid", i.e. KISS principle.

It occurs to me that you may see all this differently because you don't do the long term maintenance of your code. 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. When something changes there, yeah, I jump around a bit to figure out where the right code is, but almost always once I do, making the necessary changes is straightforward.

Tamar