G.1. Why Implement Naming Conventions?

No one has to use naming conventions. Developers can and do write applications without applying (or enforcing) naming conventions. However, they can save a lot of time, money, and prevent needless frustrations by making it easier and faster to read and interpret code, whether it is something you wrote last week or last year, or code from another developer.

Naming conventions convey many benefits. As mentioned earlier, they are like sharing a common language. Typically, that is important if the application will be shared, but it may also be applied to the individual developer who has to work with a program that was shelved for a couple of years. Some of the obvious benefits of using a naming convention include the following.

• They make object names more informative so developers can quickly understand an application's structure and code

• They provide a standardized vocabulary for team efforts.

• They minimize conflicts when adding third-party products.

• They allow code, tools, and code libraries to be shared across various VBA platforms.

• They group objects and facilitate various sort options.

• They can provide self-documenting program code.

• They enhance search and replace capabilities.

• They allow us to learn, modify, and incorporate code from others, including from magazines, reference books, the Internet, and our peers.

The naming conventions need to be an integral part of the basic design and be fully adopted before one stroke is committed to the database. It takes a little extra time upfront, but the payoff is fast. The return on investment is compounded as the application grows, becomes more complicated, interfaces with other applications, or is used by other developers.

Many developers are careful about naming tables, forms, fields, and even controls that they build. But all too often, the controls that a wizard builds are left with their original names such as Command65 or Text58. Since these names do not indicate what the control really does, they can create confusion and unnecessary conflicts, particularly if code is added. My solution is to let the wizards do their stuff, and then I promptly rename the object so that all future references to it will automatically use the correct name. Please remember that if the wizard generated code, the name of the object needs to be changed both in the object's property and in VBA.