Naming Conventions is an extremely important concept, with advantages that spread across all aspects of your Access project. Code is easily readable and can be summarized nearly at a glance, functionality of your code can be based upon the conventions you choose to use, and a plethora of bugs and errors (ranging from annoying to serious) can be avoided. After establishing a strong data foundation, the faithful use of a naming convention might be one of the most important things you can do for your project.

As a testimony to the sanity levels that can maintained through the use of naming conventions, consider the the start to finish development time for a mid-sized project being handled by a developer who employs naming conventions to one who doesn't. Naming conventions can enhance the readability of code and expressions, which in turn can reduce development time significantly. Furthermore, the (re)learning curve time is reduced when the project is revisited.

The Basic Concept: What It Is

An Naming Convention is merely a system that is used to differentiate one item from another. Generally this is employed through the use of prefixes added to the names of the item. For every object (form, report, label, control, field, table, etc etc) and every variable in your code, there should ideally be some sort of prefix to indicate what the particular item is. Here's a few examples:

• frmOrders - a form name
• rptBacklog - a report name
• strFilePath - a string variable
• ctlHourlyRate - a control name

As you can see, the concept of a naming convention is simple. The only difficult part of using one is developing a convention that works for you, and sticking to it. Keep in mind that using different conventions inconsistently throughout a project is almost as bad as using none at all. While it may take some time to develop a good convention, it should be made a priority to do so, and implementation of any changes to it should be attempted across the entire scope of the project instead of in specific areas. While you can get away with small variations in the convention here and there, a multitude of differences throughout the project becomes a complete mess to deal with later...

Common Naming Conventions

Objects

Major Objects

• tbl - Tables
• qry - Queries
• frm - Forms
• rpt - Reports
• mcr or mac - Macros
• mod, bas, or mdl - Modules
• tmp - Temporary Objects

Minor Objects

• fld - Fields
• ctl - Controls
• txt - Textboxes
• cbo - Comboboxes
• lst - List Boxes
• lbl - Labels
• lin - Lines
• img - Images
• cmd or btn - Command Buttons

Variables & Code

• str or s - Strings
• int or i - Integers
• lng or l - Long Integers
• dbl = Doubles
• cur = Currency
• bln or b - Booleans
• var or v - Variants
• arr - Arrays
• obj - Object Variables
• fnc or f - Functions
• pfnc or pf - Private Functions
• sub - Subs
• psub or ps - Private Subs
• c - Constants
• pc - Private Constants
• glb or g - Global/Public variables
• m_ - Members

Further prefixing may be used to differentiate different types of objects. For example, jtbl for Junction Tables, ltbl for Local tables, ttbl for Temporary tables, etc..

Links

• RVBA Conventions - The Reddick Naming and Coding Conventions are used by thousands of developers.

Specific Reasons for using Conventions

Reserved Words

Reserved words are, as implied, words that have special meaning in Access. Requiring variable declaration in the code (adding Option Explicit to the top of every code module) is probably the single most important thing you can do to avoid errors arising from typos and the use of reserved words, as compiling the code will identify many such anomalies. However, not every such error will be detected when you compile the code, so naming conventions are another strong line of defense against inadvertent use of a reserved word that can lead to errors ranging from annoying (something very strange is going on and I have no idea why....) to catastrophic. Errors that are not detected by compiling the code can be especially difficult to identify, as they often manifest themselves as odd happenings with no discernable explaination, and often without an actual error message. Things just don't work as expected. This is perhaps the most important reason for using naming conventions.

With a good convention applied, no name, label, variable or other identifier will ever be without a prefix of some sort or another. It is worth noting that many constants include prefixes including ac or vb, and functions including StrComp and StrConv use str as a prefix, so care still must be taken even when using a naming convention. However, a consistent naming convention significantly reduces the chance of conflicts with reserved words.

Readability

Much to the dismay of leading manufacturers of over-the-counter headache medicines, naming conventions are a Godsend for the developer when it comes to understanding code. When a developer uses consistent naming conventions throughout a project, another adept developer can, at a glance, come up with an educated synopsis of the task and the resources being used to complete that task. Without a naming convention, this can take hours to decipher. If you are a novice programmer and want others to examine your code (through a newsgroup, forum, or paid profession services), you will be greatly appreciated (and may save a lot of money) through the use of a naming convention. This really cannot be stressed enough... many can testify that there is nothing worse than trying to decipher a large chunk of code with no guidance from a naming convention.

And, we all know that at some point down the road, we will end up editing and updating our projects. Even the orignal developer of an application rarely can remember everything they were doing at the time of development... naming conventions go miles towards helping the developer quickly get back into the swing of things.

Functionality

The last thing to note here is the effects that a naming convention may have on the functional development of a project. With good practices in naming, we can use this to our advantage greatly during development, automating a number of tasks that might otherwise add up to long hours of manual work (and who wants to work when they don't have to?)

Spaces & Special Characters

In short: Don't use them!!!

While Access now allows us to use spaces in field and object names, it is highly recommended to avoid them. Use CamelCase instead and save yourself tons of time and hairpulling from the inevitable errors that come with using spaces in names.

Special characters should be a given... don't even try this (at home or anywhere else)

The characters to be most avoided are: ! @ # $ % ^ & * ( ) ? > < + = ' "; : - ~ `\ | [ ] { }

Examples of Development Functionality

As previously mentioned, Naming Conventions can be a great aid in automating some development tasks. Here's at least one example:

Setting Control Names in Forms (and Reports)

Let's suppose that part of your convention is to prefix all field names with "fld" (after all, you need to put something there so you don't wind up with field names like the reserved word "Name").

When you create a form through the use of a wizard, or when you add fields by dragging and dropping from the field list, Access will automatically name the controls for the said field with the same name as the field. This is all well and good, except that now the AccessField in the underlying form/report has the same name as the corresponding control, and there is reason for us to want them differentiated. The function below is an example of how one can utilize a naming convention to convert the "fld" prefix of the Field to a "ctl" prefix of Controls...

There, by utilizing naming conventions and running a single function from the immediate window or macro, we can save ourselves quite some amount of time by not having to manually edit each control name to differentiate between Access Fields and Controls.