Solved: Module Naming Methods and Conventions

[lwildernorva]

I did a search on module naming but found nothing quite on point so I thought I'd start a new thread. I have used Word VBA for several years but only recently noticed that the default method of naming modules ("NewMacros", "Module1") seems to violate the general principle of placing clear names in code to help us and others identify what we're doing (e.g., "strHearingSite" instead of "str1").

I also began to realize as some of my projects got larger that there would be advantages to gathering all relevant code in one module. For instance, I have a set of procedures that I use that will insert as text certain percentages and dollar values based on user input, including relevant dates, disability percentages, and wages. Rather than leaving all that code in a "Module1" with other code not related to this set of procedures, I decided I wanted to create an independent module that would allow me to find the relevant code quickly and all gathered into one place. I also realized that such a method would allow me to share the code with others simply by exporting the code in the module to a .bas file rather than by copying all of the code into a text file (which can quickly become a rather large file as you might imagine).

Well, imagine my surprise when I learned that there is no "rename" entry when you right-click on a module. Furthermore, as is frequently the case, Help is of little help in giving you direction--unless you read between the lines. If you enter "Name Module" into the Help query box in VBA, the OrganizerRename method is listed, telling you how you can rename by code. Although you can't name your project as you wish when you start it, in Word, you can use the Macro Organizer to rename the project from "Macro1" to "CompRateCalculators" as I did. You can also open the Project Properties window (F4), and on the alphabetic tab, change the name of the project in this manner.

But as we know, every action has consequences. And in this case, I'm trying to learn whether there are any disadvantages to my approach. I haven't noticed that code runs slower and am unaware that having a number of individually named projects rather than a bunch of code dumped into one module has any other adverse effects. Keep in mind that none of this code resides in the Normal template--I have learned to keep Normal lean and mean.

I guess my question boils down to: are my perceived efficiencies in implementing this method of creating multiple modules within a project and identifying them with individual names offset by any unforeseen inefficiencies?

Hope that this post has provided some useful information as well as generated some ideas.

Lee

[herzberg]

Incidentally, that's what I do for my stuff too, except that it's in Excel and not Word.

Typically, I have 3 modules: ImportAll (to import whatever I need), ProcessData (to do whatever processes needed) and CleanUp (to delete whatever that is not needed). Of course, more modules may be added, depending on situation.

I find this arrangement to be helpful, especially if I revisit the project after a month or two. Instead having search through one massive module, I can identify the relevant module quickly and locate what I want easily. And like you said, exporting modules is a breeze too.

So far, I have't seen speed/performance decline due to mutiple modules. Honestly, I don't see why we should be penalized for trying to keep the code neat and organized. :)

[gwkenny]

Well, imagine my surprise when I learned that there is no "rename" entry when you right-click on a module. Furthermore, as is frequently the case, Help is of little help in giving you direction--unless you read between the lines.

Microsoft can be mighty helpful can't they!!! I remember when I was told that they new about a bug I found but they had no plans to fix it anytime in the near future (the bank I was at was testing their new Office software). I was able to talk to a Microsoft programmer and he told me they had too many other major problems to worry about!!!! lol

Anyways... You can change module names. Click the module and look at the properties window. You'll see a "name" property. Just change it there.

I develop my code in separate modules as well. Usually there's a core task. That's in one module (if the task is small enough). Then there's supporting tasks. That goes in another. Then there's codes/userforms I use all over the place in several routines (for example, progress bars) which I put in yet another module named Utilities.

[fumei]

I agree with explicitly naming, along with grouping of procedures. For example, in my global template I have:

modStringFunctions - contains all sorts of...string functions
modBookmarks - procedures that deal with bookmarks
modFormfields - procedures that deal with formfields
modTables - procedures that deal with tables

etc. etc.

I am with gwkenny on the renaming, the easiest way is simply change the name in the properties. It is the first thing I do when I make a new module, before I even start putting procedures in it.

[lwildernorva]

Thanks. I didn't think there was a problem but wanted the input before creating tons of new modules. Agree that it's easier to rename using the Project Properties window but in looking for solutions realized the Organizer solution would also work although it is not as elegant. Again, nothing in Help informs you of either solution, however.