separate modules for each sub routine?

[smokiibear]

I'm looking for feedback on whether or not to create separate modules for
each sub-routine and function, or to combine them in them in single modules
(where it makes sense). I realize this may be like asking what is the
"best" flavor of ice cream, but I'm curious to hear what reasons people
have for their preference on this matter.

Thanks for your interest and opinions.

Smokii

 

[Tom Ogilvy]

It would seem cumbersome to have numerous modules with no specific purpose
nor advantage. I would use modules to group logically related subs and
functions. I suspect there is some overhead to having each module in
terms of file size.

 

[Bob Phillips]

Having separate modules for each routine is making it very difficult if you
have hundreds within a project, scrolling down the explorer list will not be
easy.

Similarly, having them all in one module is just as unmanageable.

IMO, far better to use the latter suggestion, group them in modules based
upon functionality. By naming the modules sensibly as well, you get a good
hierarchical order, and will find it a bit easier when you come to amend
things in a year's tine .

--

HTH

RP
(remove nothere from the email address if mailing direct)

 

[Guest]

Hi,

Probably stirring a hornet's nest here, but ...

My own view would be to have all the functions (or subroutines, which I
won't keep typing) which are linked in some way in one module. Linked could
be "doing related functions" e.g. encoding something and decoding it or one
main routine with various subroutines it calls. This also has the advantage
of being able to use Private for functions that you don't want users to be
able to call directly.

I guess you can think of this as a simple case of developing a class, where
functions and data are all in one place.

That's my view. I'm sure there will be others.

Regards,

David Jessop

 

[Don Guillett]

Personal preference.

 

[Tushar Mehta]

Yep. I prefer chocolate with nuts, preferably almonds or pecans. {g}

Logical organization is what I use. One module manages menus. That
also makes it trivial to copy it to another add-in. One module
includes all publicly exposed subroutines (typically, associated with
menu items / command bar items). If the add-in is large, I might have
individual modules each of which provides some functional capability.

Of course, some modules / code placements are dictated by language
requirements. For example, even if a functional capability requires 2
or more classes, I am forced to create separate class modules rather
than put them in a single project 'block.'

--
Regards,

Tushar Mehta
www.tushar-mehta.com
Excel, PowerPoint, and VBA add-ins, tutorials
Custom MS Office productivity solutions

 

[Guest]

The only technical limitation that I am aware of:
the first project I ever wrote I put all code in a single module. At some
point it started crashing. I was advised that problems can occur with very
large modules.

After breaking up the code into logical sections the problem disappeared.
Whether this was due to reducing the module size or perhaps I modified the
code in the process I cant be sure. Just speculation and hearsay.

 

[Tom Ogilvy]

The hearsay is that modules shouldn't exceed 64K. This can be checked by
exporting the module as a bas file and then check the file size.