Naming Objects in Access: A Proposed Standard
By Stan Leszynski and Greg Reddick

This article was first published in the February 1993
(Charter) issue of Smart Access, a monthly technical
journal published by Pinnacle Publishing.  Please call
800-788-1900 or 206-251-1900 for information on 
subscribing to Smart Access.

A successful artist, craftsman, or athlete becomes 
noted for his or her unique style, or approach to a 
craft. Likewise, a successful database developer 
evolves his or her unique style, reflected in the 
design and programming of an application. A database 
development style includes approaches to naming 
objects, organizational tricks, solutions for common 
problems, and for commenting code.

Any database developer who has inherited a project from 
another developer knows how frustrating it can be to 
try to dissect another's style and maintain another's 
code. Further, for the Microsoft Access development 
community to prosper, we will all be sharing code ideas 
and libraries with one another through this 
publication, CompuServe, and other forums. 

In order to best share ideas and knowledge, the Access 
development community would be well served to adopt a 
common programming style so that developers can benefit 
from one another's expertise with a minimum of 
translation overhead. To date, Microsoft has not 
recommended or endorsed a development style for Access, 
so the readers of this journal have an opportunity to 
create and adopt a standard that will live on for many 
years to come.

This article describes a set of object naming 
conventions for Access that we have developed over the 
past year as part of a larger effort to standardize our 
programming style. In it, we have combined our 
proficiency in many database languages with our 
experience in Basic and C and tried to create a style 
that would meet the unique needs of the Access 
community. We suggest that you try these naming 
standards in your own development work and encourage 
their use by other Access users that you share code 
with.


Naming Conventions  An Overview
Our naming conventions are based on a method of naming 
called Hungarian, referring to the nationality of its 
creator, Charles Simonyi (who, incidentally, worked on 
Access for a while). Some elements of the Hungarian 
style are currently used in the Microsoft Visual Basic 
2.0 manuals and the Microsoft Windows SDK manuals, 
among others. Microsoft uses Hungarian internally in 
almost all program development. We have adapted the 
Hungarian style to the Access environment.

Getting used to these naming conventions may seem a 
little strange at first, perhaps like reading Hungarian 
would be. However, after using it for a brief time, you 
will find that it becomes second nature and that it 
makes reading and understanding code faster and easier.

The Components of a Name
In our Access naming style, object names are made up of 
four parts:  the base name, the tag, the prefix, and 
the qualifier. The base name and tag are required. The 
prefix and qualifier are optional. The four parts are 
assembled as follows:

[prefix]tagBase[Qualifier]

Prefixes and tags are always in lowercase, so that your 
eye goes past them to the first upper case letter where 
the actual base object name begins. This makes the 
names more readable. The base and qualifier components, 
however, begin with an upper case letter. (The brackets 
surrounding prefix and Qualifier denote that these 
components are optional. The brackets are not part of 
the name.)

The object base name is the part of the name that 
succinctly describes the object (not its class). This 
is the name you would likely give the object if you 
weren't using any particular set of naming conventions. 
For example, in the query name qryPartNum, "PartNum" is 
the base name; it is an abbreviation for Part Number.

Object tags are generally short (typically one to four 
letters) and are mnemonic. For the benefit of C 
programmers, some of the tag names in our style are 
derived from similar usage in C, even if the mnemonic 
connection is somewhat stretched in Access usage. For 
example, "w" is the C tag for an integer value because 
it is stored internally as a word, so wPartNum is a 
part number variable dimensioned as Integer. Although 
Access programmers do not concern themselves with 
storage mechanisms to the same degree as C programmers, 
we believe it is better to stretch an existing standard 
rather than create yet another. (If you are a C 
programmer, you are sighing with relief at this point!)

Object prefixes precede some object names and tags and 
provide further information. For example, if our 
variable wPartNum above is actually an Integer array of 
part numbers, the prefix "a" for array is added to the 
front (awPartNum()). Further, a variable that provides 
an index into the array would use the name of the array 
prefixed with the index prefix "i" (iawPartNum).

Object qualifiers may follow a name and serve to 
further clarify names that are similar. To continue 
with our parts index example, if you kept two indexes 
to the array, one for the first item and one for the 
last, the variable iawPartNum above would become two 
qualified variables (iawPartNumFirst and 
iawPartNumLast).


Naming Database Objects
Database objects (tables, queries, forms, reports, 
macros, and modules) are the most frequently referenced 
items in your Access application. They may appear in 
your macro code, in your Access Basic code (ABC) 
routines and in properties. Thus it is important that 
you standardize how you name database objects.

While Microsoft's examples in the Northwind Database 
and Access manuals allow for spaces in object names, we 
do not use spaces in our standard. One good reason is 
that spaces require you to use the left and right 
bracket when specifying the name of the object. Inside 
a form object definition, where you already have 
exclamation points and periods, the bracket syntax 
becomes very confusing. Another reason is that spaces 
in field names do not work on most other database 
platforms. If for some reason you need to port your 
database schema to another platform, the spaces would 
make it difficult. Instead of spaces, use upper case 
and lower case designations in names, such as 
tblInventoryControl, to make it more readable. If some 
kind of spacing is still necessary, use the underscore 
(_) character instead of a space to be consistent with 
Microsoft SQL Server and other databases.


Tags for database container objects
All database container object names in our style have 
tags. Although adding tags to these objects makes them 
less readable to nondevelopers, even new users will 
understand their value when trying to discern a table 
from a query in the picklists for a New Report wizard 
or a form's Control Source property, where table and 
query names are merged into one long list.

These are the database container object name tags:

----------------------------------------
Object             Tag   Example
----------------------------------------
Form               frm   frmFileOpen
Macro              mcr   mcrMainMenu
Module             mod   modLibrary
Query (select)     qry   qryOverAchiever
Query (append)     qrya  qryaNewProduct
Query (crosstab)   qryc  qrycRegionSales
Query (delete)     qryd  qrydOldAccount
Query (make table) qrym  qrymShipTo
Query (update)     qryu  qryuDiscount
Report             rpt   rptInsuranceValue
Table              tbl   tblCustomer
----------------------------------------

As you can see, we recommend different tags for the 
different types of action queries. Since the difference 
between a Make Table query and an Append query is 
important to your application, and potentially 
destructive to data, we choose to denote the action 
query type directly in the name (qrymSalesSummary vs. 
qryaSalesSummary).

We suggest using the prefix "zz" to denote objects that 
you have deserted but may want to keep in the database 
for awhile for reference or reuse (for example, 
zzfrmPhoneList). The "zz" prefix causes the object name 
to always sort to the bottom of the database container, 
where it is available but "out of the way." The other 
database object prefix in our convention is "zt" for 
temporary objects, as described later.

The only name qualifier (appended to the name) that we 
use for database container objects is Sub, which is 
placed at the end of a form/report name that is used as 
a subform/report. The form frmProductSupplier would 
have the related subform frmProductSupplierSub. This 
allows items and their subform(s) and subreport(s) to 
sort next to each other in the database container, 
which makes development easier.

We suggest that you choose your table names carefully, 
then name each database object that refers to that 
table with the same name, using the appropriate tag to 
differentiate them. For example, if your table is 
tblCustomer, its primary form would be frmCustomer, its 
primary report would be rptCustomer, and the macro that 
drives all of its events would be mcrCustomer.


Tags for fields
Whether or not to use naming convention tags in field 
names is a hotly debated issue, even within our 
company. Proponents maintain that it uniformly applies 
the naming standards across all database elements, and 
further documents your work in ABC routines and 
form/report properties. Opponents of field name tags 
prefer that the database schema remain pure (platform 
and datatype independent) for migration and 
connectivity to other products or platforms, and they 
note that system documentation delivered to clients is 
easier to read without the tags. You will have to 
consider both these positions, along with your unique 
needs, when you choose whether or not to apply these 
suggested prefixes to fields:

----------------------------
Field Type  Tag  Example
----------------------------
Byte        byt  bytFloorNum
Currency    cur  curSalary
Date/Time   dat  datHireDate
Double      dbl  dblMass
Counter     cnt  cntPK
Yes/No*     f    fDiscounted
Integer*    w    wUnits
Long*       dw   dwPopulation
Ole         ole  oleEmpePhoto
Memo        mem  memComments
----------------------------
Items marked with * above are taken from standard C 
conventions.


Tags for control objects
All control object names in our style recommendation 
have tags. These control objects, such as text and list 
boxes, appear on forms and reports:

-----------------------------------
Object          Tag  Example
-----------------------------------
Chart           cht  chtSales
Check box       chk  chkReadOnly
Combo box       cbo  cboEnglish
Command button  cmd  cmdCancel
Frame           fra  fraLanguage
Label           lbl  lblHelpMessage
Line            lin  linVertical
List box        lst  lstPolicyCodes
Option button   opt  optFrench
Option group    grp  grpChoices
Page break      brk  brkPage
Shape           shp  shpCircle
Text box        txt  txtLoginName
Button          tgl  tglForms
-----------------------------------

Access forms and reports automatically assign the field 
name to the Control Name property when creating a new 
bound control. In this scenario, the control name and 
field name are the same, creating some ambiguity in the 
database schema. To resolve this situation, apply our 
naming conventions to form and report controls by 
inserting the appropriate tag from the list above in 
front of the Control Name suggested by Access. For 
example, locating the LastName field as a text box on a 
form yields a Control Name property of LastName for the 
object. Simply edit the property and add the required 
tag to the Control Name (txtLastName).


Tags for Access Basic code
The need for Access naming standards grew out of the 
fact that Access Basic is a powerful language that can 
create robust ( but complicated) applications. Using 
standardized and descriptive variable, constant, and 
function names greatly enhances the ability of 
developers to share, maintain, and jointly develop 
code.

Every ABC variable should have a type prefix from the 
following list:

-----------------------------------------------
Variable Type  Tag   Example
-----------------------------------------------
Control        ctl   Dim ctlVapor As Control
Currency       cur   Dim curSalary As Currency
Database       db    Dim dbCurrent As Database
Double         dbl   Dim dblPi As Double
Dynaset        ds    Dim dsTransact As Dynaset
Form           frm   Dim frmGetUser As Form
Integer*       w     Dim wRetValue As Integer
Long*          dw    Dim dwParam As Long
Query          qry   Dim qryPrice As QueryDef
Report         rpt   Dim rptYTDSales As Report
Single         sng   Dim sngLoadFactor As Single
Snapshot       snp   Dim snpParts As Snapshot
String*        sz    Dim szUserName As String
Table          tbl   Dim tblVendor As Table
Variant        var   Dim varInput As Variant
-----------------------------------------------
Items marked with * above are taken from standard C 
conventions.

You will notice that tags for database object variables 
such as the Form and Report types are the same as those 
used for the objects themselves. This helps when coding 
because the variable you assign an object to (for 
example, tblVendor) usually will have the same name as 
the object it references (tblVendor), providing you 
with one less name to remember when coding.

When creating temporary database objects via code, such 
objects may appear in the database container in a 
multi-user setup. For such temporary objects, we 
suggest using the prefix "zt." This causes the object 
to sort to the bottom of the active items in the 
database container, where they will minimally distract 
other users (but still above unused objects prefixed 
with "zz"). Temporary objects that are not properly 
deleted by the code that creates them will show up in 
your database container grouped together by the "zt" 
prefix, which may help debugging efforts.

As noted earlier, two prefixes precede variable name 
tags to provide further information. The first prefix 
is "a," used for arrays and added to the front of the 
name (awPartNum()). The second prefix is "i," which 
denotes an index into an array and uses the name of the 
array prefixed with the index prefix (iawPartNum).

We also noted earlier that object qualifiers follow the 
variable name and further differentiate it from similar 
names. You will probably devise your own long list of 
qualifiers that are relevant to the types of 
applications you develop, but here are some of our 
common ones:

-------------------------------------------------
Variable Property       Qualifier  Example
-------------------------------------------------
First element of set     First     iawStockFirst
Last element of set      Last      iawStockLast
Next element of set      Next      szCustomerNext
Previous element of set  Prev      szCustomerPrev
Lower limit of range     Min       iaszNamesMin
Upper limit of range     Max       iaszNamesMax
Source                   Src       dwBufferSrc
Destination              Dest      dwBufferDest
-------------------------------------------------


Here is an example of an ABC routine using these naming 
conventions:

Function RowCount (szTableName As String)
' Get the number of rows in a table
' Passed in: table name  Passed back: row count or 0
Dim dbCurr As Database
Dim snpRows As Snapshot
Dim dwRows As Long
' Open current database
Set dbCurr = CurrentDB()
' Get the system table list
Set snpRows = dbCurr.ListTables()
' Assume 0 or we cannot find it
dwRows = 0
' Look for the table name
Do Until snpRows.EOF
' Is this the one?
If snpRows![Name] = szTableName Then
' ...get the count and exit
dwRows = snpRows![RecordCount]
Exit Do
End If
'  Still looking for the table
snpRows.MoveNext
Loop
' Close the table
snpRows.Close
RowCount = dwRows
End Function


Putting Standards into Practice
Proper use of naming conventions should not be viewed 
as a surrogate for good comments in your table 
definitions, macro code, and ABC routines. Naming 
conventions are an extension of, not a replacement for, 
good program commenting techniques.

Formulating, learning, and applying a consistent set of 
naming standards requires a significant initial 
investment of time and energy. This up-front time, 
however, will be more than made up for when you return 
to your application a year later to do maintenance or 
when you share your code with others. Once implemented, 
you will quickly grow to appreciate the effort you made 
in standardizing the naming of items.

If the entire Access community, including Microsoft 
itself, coded to one common naming standard, we would 
likely all find it easier to share information about 
Access. It is with this in mind that we submit this 
proposed standard to the Access community. 

(Editor's Note:  Leszynski and Reddick's naming 
conventions, as outlined in this article, are now the 
preferred naming standard for Smart Access. Authors 
submitting future articles are encouraged to use this 
well-conceived standard.)


About the authors
-------------------------------------------------------
Stan Leszynski is president of Kwery Corporation, which 
produces several Access add-on products, including the 
Access Documenter and Access To Word. Stan also founded 
Leszynski Company, a database consulting group, in 
1982.  He can be reached at 206/644-7826 or on 
CompuServe at 71151,1114.

Greg Reddick is a vice president of Kwery Corporation. 
He worked for four years on the development team for 
Access at Microsoft. He is a coauthor of Inside 
Microsoft Access for New Riders Publishing. Greg can be 
reached at 206/644-7830 or on CompuServe at 71501,2564.
