There seem to be a ton of naming conventions out there for Access objects, variables in vba, etc. Is there a preferred method used most commonly with Access 2010 VBA? If not, then I can take one of the existing models to use.

JT

I did find a nice convention in the WIKI. http://www.UtterAccess.com/wiki/index.php/Naming_Conventions

JT

There are 127 standard naming conventions for Access objects. One of them is correct, the other 126 are wrong, evil, perverse and vile.

Unfortunately there is great disagreement and contention over which of them is correct.

I'm just going to drop my two bits. Most Access programmers still use a convention where tables, forms, reports, queries, modules, and variables are prefixed with (usually) 3-digit prefixes such as tbl, frm, rpt, qry, mdl or mod, str, int, lng, sng, dbl, obj, var, typ, etc.

If you listen to the programmers at StackOverflow (many of them SQL Server and/or C# programmers) you will find that using these conventions are now considered to be outdated and a poor practice, especially in a language such as VBA that can be used as a strongly typed language (nothing to necessarily enforce strong typing).

The one practice which I did for a while, and have since discontinued, was naming table fields with a 3 letter prefix. Basically, I ran into two problems. It was somewhat troublesome to remember what the prefixes were and made for even longer, more unwieldy queries. My other complaint was that from time to time I find out that I've used the wrong data type for a field and need to change it later. Simply changing a fields data type then requires you to change the fields name as well. This means you then have to update all your forms, queries, reports, and code. Or at least in my cased, I have to since I'm using SQL Server with ODBC Linked Tables.

I still continue to forms, reports, queries, modules, etc. following common Access conventions. I've now shortened my variable names to use only a single letter prefix with the exception of singles (which I almost never used), doubles, and types. The only problem with this is that these conventions do not really line up with the larger Access community.

Oh, and I should mention. I think the most important place to use naming conventions is on controls. I like to be able to differentiate between a control and a form level field so I want them to have different names. I don't always rename labels or boxes, but I'm pretty diligent about renaming everything else. Here's a few examples:

Checkbox: chkSelected
Textbox: txtFirstName
Combo: cboCountry
Listbox: lstVendors
Subform: fsubVendors or subform1
Button: cmdPrintPreview

The other thing I want to mention is that I never uses spaces or symbols (except underscore) in any of my names. In my opinion, this is a very important convention or best practice to follow.

I appreciate the details you provided hk1 along with some cautions. I'm going to follow something similar to what you do.

John, didn't you forget that "MY" way is right! lol

JT

JT,

Just deciding to USE a naming convention is a step in the right direction. Make your names meaningful and consistent so that you, and the people who may one day need to maintain your database, can figure out what they do.

The recently-criticized Hungarian Notation is my personal favorite. For the record, I prefix my table names with "tbl" and my query names with "qry" - that way when I'm dealing with one or the other in VBA code, I know immediately where my data is coming from.

I not only name my larger objects this way ("frm..." for a form, "rpt..." for a report, etc.), but I also name my controls ("txt..." for textboxes, "cmb..." for comboboxes, etc.), fields ("lngEmployeeID", "strFirstName", etc.) and variables in the same way. By prefixing an Integer field name with "int" and a Long Integer field name with "lng" helps me to figure out what's going wrong when I try accidentally mix them up and cause an error.

You may end up taking bits and pieces from several methods - just try to remain consistent and meaningful, and you'll do fine. There are few things more frustrating than being handed some ex-employee's database with variables named "X", "BRT" and "OTH" when VBA allows you to name things like "boolContainsNuts" or "intVolunteerCounter".

Dennis