philosophical question about programming best practices

[c1802362]

Hello all,

I am looking for perspective on VBA (and general programming) methods,
specifically:

In an application I'm writing in VBA, I have multiple forms. These
forms run different utilities, but they share the same drop down
lists, input fields, and cancel buttons, among other things. The forms
are kept separate as different users require different utilities.

Is it good programming practice to utilize the same name and code for
a drop down list of months, for example, which would appear on
multiple forms, or should I just duplicate the code, renaming the
variables?

Pros and cons eagerly sought...

Art

 

[GS]

c1802362 explained :

Hello all,

I am looking for perspective on VBA (and general programming) methods,
specifically:

In an application I'm writing in VBA, I have multiple forms. These
forms run different utilities, but they share the same drop down
lists, input fields, and cancel buttons, among other things. The forms
are kept separate as different users require different utilities.

Is it good programming practice to utilize the same name and code for
a drop down list of months, for example, which would appear on
multiple forms, or should I just duplicate the code, renaming the
variables?

Pros and cons eagerly sought...

Art

How about using a single userform that shows different 'pages' for the
different utilities. That will obviate the need for duplication of
common controls. In this scenario each 'page' would signify which
'utility mode' the user is in and so the underlying code will handle
processing appropriate for the 'mode'.

The structure of the userform in this case would be like that of a
'wizard', where each page serves a different purpose. I use Frames as
my pages but you could use a MultiPage to do similar. (I find using
Frames easier and can be more compact when needed, plus reduces extra
file 'bulk' and resources overhead from using so many userforms) Page
display is handled by a ShowPage function that takes the index of the
page to display, and (optionally) a list of any 'common' controls to
display that are not outside the page somewhere on the userform. (any
controls common to all pages are on the area outside where the pages
display)

--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion

 

[Martin Brown]

Hello all,

I am looking for perspective on VBA (and general programming) methods,
specifically:

In an application I'm writing in VBA, I have multiple forms. These
forms run different utilities, but they share the same drop down
lists, input fields, and cancel buttons, among other things. The forms
are kept separate as different users require different utilities.

One way would be to make one form that can hide the bits that some
people don't use and have a hidden configuration settings page.

Is it good programming practice to utilize the same name and code for
a drop down list of months, for example, which would appear on
multiple forms, or should I just duplicate the code, renaming the
variables?

Duplicating code just creates maintenance traps for the future.
If you can write stuff in a way that the whole thing is reusable
elsewhere without any modifications then you should do it that way.

Picking a month is a pretty good example since you can be very sure that
the specification is not going to change at the whim of some PHB.

Pros and cons eagerly sought...

Art

Avoiding unnecessary code duplication is wise. You might also find this
Wiki page on cohesion helpful as a guide to best practice.

http://en.wikipedia.org/wiki/Cohesion_(computer_science)

Too much VBA code that I see has mostly coincidental cohesion.

 

[c1802362]

Martin/Garry -

I strongly agree with both of your suggestions.

The reason I had been hesitant to have a frame or tab form is that I
wanted to control which users see which utilities - however, your
suggestion to tailor the forms to the user by locking out the uneeded
parts is a great suggestion - I'll start working through that problem

Having only one set of code is always the correct solution. I aspire
to the 'Functional Cohesion' as described in the wikipedia aritcle,
but have been successful only to a point - lots of times, I can reuse
the code almost verbatim, but I may need to tweak one line to achieve
a specific function.

Thanks again

Art