Anything wrong with this approach to programming? - Part II

I posted earlier on a similar topic (see thread "Anything wrong with this approach to programming?") , and received some really great responses. Now, I have a few more questions that are a lot more specific.

For those that didn't read my last thread, I was asking about adding a new form to my existing project. The new form behaves almost exactly the same as the old form, so I'm trying to enhance my code as much as possible. Anyway, here are my questions...

1) Since both of my forms are the same, is it okay to name all of the controls on each form the same thing? I'd like to do that because there are times where I refer to my form within a function or class. For example, sometimes I run a query in a code module, and then loop through the query populating values on a form within that same function. If I name all of the controls on both forms the same thing, then that makes my classes much simpler.

2) We all know duplicate code isn't great. But what if both of my forms have a click button with two or three lines of code in it that are all the same. Is it worth creating a function or class to eliminate the duplicate code in this case? That kind of takes us back to the whole control thing again, naming them all the same.

Any tips are appreciated.

- The_Grudge

If you have controls on separate forms that perform the same fundamental function, then not only is there nothing wrong with giving them the same name, I believe it promotes consistency.

Quote:

---

Originally Posted by The_Grudge

But what if both of my forms have a click button with two or three lines of code in it that are all the same. Is it worth creating a function or class to eliminate the duplicate code in this case?

---

If it is one button on two forms, then I would just code the button rather than build a functions.

If, however, that grew to one button on multiple forms, then I'd look at a function.

Regarding 1) , the names are irrelevant - simply pass the controls as parameters to the function/class (there is an article in the Classic VB FAQ if you aren't sure how to do it). I do agree tho that they should be named the same for consistency.


Is there a reason for two separate forms tho?

I would have one form which contains all of the common code, and then have a class for each 'instance', which performs the code that is unique to each.

You can create applications quickly that way, no argument on that point... my concern though is you might end up blurring the distinction between interface/presentation, business logic, and data access... any changes to your interface would affect processing modules (code module or algorithm) as well as data access modules/algo, etc etc...

at the moment the only case I can think of that its ok to pass interface objects would be to pass references to controls (such as multicolumn lists) containing data so you won't have to setup data structures in between... im sure there are other cases when its ok but i'm too sleepy to remember them :P