Naming Conventions

General

As novice developer you usually define names for constants, variables and methods as they occur; you look at a problem, think of a function, add some parameters and that's it.

After a few years of coding—especially once you are forced to refactor some of your legacy coding—you will realize that the code is hard to read; it somehow feels "inconsistent".

Also during normal development you will notice that you keep stumpling upon the same issues again and again: you're trying to access variables, which are not accessible, you try to use a variable for a text value and run in to an error as it has been defined for numbers: the list of little annoyances which are implied when not sticking to consistent conventions is long—add your favourite annoyance here.

The naming conventions depend on the language you are using, but for VBA it is common conviction to use either the Reddick VBA Naming Conventions or the Leszynski VBA Naming Conventions, which are both versions of the Hungarian notation.

The main idea is to embed the variable name into prefixes and suffixes in order to give the developer a hint about the scope, purpose and data type of the variable. The general pattern is:

[ Prefix ] Tag [ Discriminator ] [ Name ] [ Suffix ]

where

• Prefix is used to describe the scope of the variable
• Tag is used to indicate the data type of the variable
• Name is a brief description of the variable's purpose or content and
• Suffix standardize often used versions of the same variable and are basically derived

from the database aggregate functions (Count, Min, Max, Sum, Avg, First, Last) or other special properties describing the order like "ByDate", "ByCustomer" etc.

Name

Singular

All names will be in singular form. A table, for example, represents many uniformed records. Do we want to talk about many records or do we talk about the entity that table has been designed for? It is the entity.

Let's look at it with a semantic focus: We have a table "Books" which has a field "ISBN". When we are talking about "Books.ISBN", do we mean all ISBNs of all Books? Or the ISBN of a certain Book? It is usually the latter. It also makes SQL statements and code much more readable besides the fact that mixing plural ("Books") and singular ("ISBN") does not make sense. Example:

    SELECT Book.Isbn
      FROM Book
INNER JOIN Stock
        ON Book.Isbn = Stock.BookIsbn

Collections

Another advantage of generally applying singular names is the option to denote collections and arrays with a plural form, which leads to easily understandable code like

For Each varBook In varBooks
    varBook.Isbn = "unknown"
Next varBook

In case

• the singular form should equal the plural like with Status,
• the name itself describes an entity which consists of many items like with List

or similar scenarios there is another collection naming convention: The collection keeps the name of the entity (Status, List) while its elements are suffixed with Item:

For Each varListItem In varList
    varListItem.Active = "yes"
Next varListItem

Tag

A tag is a usually three letter long lowercase mnemonic for the variable type. As there is not a tag for every kind of variable, you sometimes need to "invent" a tag of your own. The usual steps for finding an appropriate tag are:

1. Take the name of the object type
2. Remove all vowels from the name; you may keep the first vowel if necessary
3. Take the first three letters

As soon as you found a tag you should consider the following questions too:

• Is the tag already taken by another object type?
• Does it phonetically sound like the object type?

If you should answer one of these questions with "yes", you should adjust the tag name accordingly.

Data Type

Tag: Data Type

Data Type	Tag
Boolean	bln
Integer	int
Long	lng
Single	sng
Double	dbl
Currency	cur
String	str
Date	dat
Variant	var
Array	arr, var
Type	typ
Object	obj

Microsoft Office

Microsoft Office Objects

Tag: Microsoft Office Objects

Data Type	Tag
Menu Bar, Tool Bar	cbr
Menu Item
Module	mod
Class	cls

Microsoft Office Form Objects

Tag: Microsoft Office Form Objects

Data Type	Tag
Control	ctl
Label	lbl
Text Box	txt
Combo Box	cmb
List Box	lst
Check Box	chk
Button	btn
Option Group	grp
Option Button	opt
Tab Control	tab
Tab Control Page	tpg, pag
Frame	fra
Frame bound	frb
Frame unbound	fru
Image	img
Line	lin
Page Break	brk

The following tags differ slightly from tags proposed by Reddick and Leszynski and should be explained:

cmb vs cbo

The control type name is "Combo Box". If you apply the tag rules you will end up with cmb. There is no good reason to call this control type tag "cbo".

btn vs cmd

The nature of a "Command Button" is not the command, but the button. The tag "cmd" is also well known for the Windows Shell as well as for the extension of batch files. Although both usually do not appear in Visual Basic code very often it is still a bad habit to "abuse" acronyms.

tpg/pag vs pge

The tag "pge" is less phonetic than "pag". A good tag would be "pg", but as we are trying to stick with three-letter tags, we need to find something suitable. Pages do not exist without their container, the "Tab Control", thus it is okay to see this control as "Tab Page" ending up with the tag "tpg".

tgl vs btn

You may decide on your own whether you should use a different prefix for a toggle button. In the end it is still a button although it rather behaves like a check box.

Microsoft Access

Tag: Microsoft Access Objects

Data Type	Tag
Table	tbl
Table Field	fld
Query	qry
Form	frm
Sub Form	sfr
Report	rpt
Sub Report	srp

Microsoft Excel

Tag: Microsoft Excel Objects

Data Type	Tag
Workbook	wbk
Worksheet	wks
Range	rng
Chart	cht
Shape	shp

Prefix

Scope

Class, Module, Public, Private ...

Discriminator

Constants

Constants get a c after the tag:

Private Const intcAnswer As Integer = 42

Class Properties

Reddick recommends to apply the naming conventions to class properties as well unless you are distributing the class to customers, who might not be aware of those conventions.

The purpose of a class is to encapsulate business logic and to hide the complexity of the underlying code from the user. In order to make the code more readable it is strongly recommended to leave out the naming convention amendments when it comes to naming the properties of a class module.