Naming Conventions

Naming conventions are one of the most important concepts in programming and yet are rarely taught. It's easy to ignore the importance of a systematic approach to naming variables , procedures, and so on - but once you start programming in earnest, you'll realize that not only does a set of conventions make thinking up new names easier, but it is a tremendous help when it comes to understanding the code you have written. For example, if you follow a set of conventions, you will be able to tell at a glance a variable's type and where it was declared (that is, whether it is local or public). This will save you having to look for the variable declaration to find this out - a process which can be especially tedious if you have several modules and public variables.

Naming conventions are, of course, a matter of personal taste and you should use whichever set of standards you prefer. An important consideration is to use standards that will help others maintain your code in the future. There are no hard and fast rules (the ones shown here are fairly standard, although other people may use slightly different prefixes that the ones we've shown). All we can do is list our favorite set of conventions and let you make your own mind up.

Keep Names Meaningful

The first rule is to make variable names meaningful. They should describe what they hold. If you have a variable that holds someone's age, then call it Age . A birth date should be stored as DateOfBirth , or date_of_birth . We prefer the first method without the underscores, since we think it looks neater, but you can choose any style. The important point is to be consistent. If you have a system, then stick to it.

Mixed Case Naming

There are some generally accepted rules about procedure naming that are worth mentioning here. Long ago it was necessary to use vary short and cryptic names due to the system limitations at the time. Early operating systems didn't differentiate between upper and lower case characters . These days, disk space and memory is not so much of a premium commodity and lengthy names don't significantly affect performance. Since you can't have spaces in a procedure name, you take the name for your procedure (usually a short phrase), cram all of the words together, and capitalize the first letter of each word. This is known as PascalCase. For example, if we're creating a function to return a list of ingredients , we might call it GetIngredientsList() .

Prefix All Variables and Constants With Their Type

If you use a prefix, you can easily see what type the variable is. For example, if Age was stored as an integer, then you should use int as the prefix, giving intAge . The prefix is lower case to separate it from the variable name. This form of naming is known as Hungarian notation, and we will be using throughout the book. The most commonly used prefixes are listed below:

Variable Type	Prefixes	Variable Type	Prefixes
Integer	int	Variant	var
Long	lng	Date	dat dte
Single	sng	Boolean	bln
Double	dbl	Byte	byt
Currency	ccy cur	Object	obj
String	str	Hyperlink	hyp

It's also a good idea to add a double prefix for the variant type. Use var to denote that a variant is in use, but add another prefix to denote the type of data the variant will store. For example, if the age was to be stored in this way, you could use intvarAge .

Prefix Global Variables with their Scope

Yet another prefix. Will it never stop? This is the last one and, in some ways, the most useful since it can be a great time saver. Use a prefix to denote the scope, that is, whether it is a local, module or public variable. You can leave the prefix for local variables blank, since most will be local, but use m_ for module level, g_ for public (global) variables, and s for static variables in procedures. Thus if Age was a public variant holding an integer value, it would become g_intvarAge .

OK, so in this case the prefixes are now larger than the variable name, but on the other hand you can see everything about this variable from its name. What could be clearer?

Naming Conventions for Controls

In the same way that you use conventions for variables, you should also consider using them for controls on forms and reports , especially if you are going to refer to these controls in your code.

Control	Prefix	Control	Prefix
Chart (graph)	cht	Option button	opt
Check box	chk	Option group	grp
Combo box	cbo	Page break	brk
Command button	cmd	Rectangle	rec
Frame	fra	Subform/report	sub
Label	lbl	Textbox	txt
Line	lin	Toggle button	tgl
Listbox	lst	Hyperlink	hyp

The principle is exactly the same as for variables and, again, will make your code easier to read:

   Function GetName () As String     Dim strName As String     strName = txtFirstName & " " & txtLastName     GetName = strName     End Function   

It immediately becomes obvious that the first and last names are stored on the form in textboxes.

Now that the use of ActiveX controls is becoming widespread, you may find you wish to use controls that do not fit into the above list. In this case just use a prefix that you find suitable. For example, we will be looking at the Calendar control later on, and for this you could use cal .

Naming Conventions for Objects

The same principle should be applied to objects, both in code and in the database window. So when you save your tables, queries, forms, and so on, follow the same principle:

Object	Prefix	Object	Prefix
Table	tbl	Group	grp
Query	qry	Container	con
Form	frm	Document	doc
Report	rpt	Index	idx
Macro	mac	Field	fld
Module	mod	Property	pty
User	usr	Page	pag

You may not have come across many of these objects yet, but you will meet a few more as the book progresses.

Naming Conventions for Constants

For constants you follow a similar style to variables, although some people prefer to have their constants all in capitals. We recommend using a c at the front of the name, to indicate a constant, and then the prefix for the type, making sure that you always specify the type of the constant. For example:

   Const clngSpeedOfLight As Long = 299792458     Const cstrCleverPerson As String = "Albert Einstein"   

or a slightly shorter form:

   Const clSpeedOfLight As Long = 299792458     Const csCleverPerson As String = "Albert Einstein"   

Naming Conventions Summary

All of this may seem rather cumbersome and a waste of effort, but as your programs become larger, you will find it essential to be able to identify different variables/controls/objects. If you start using conventions as you learn the language, it will soon become second nature and, after a while, you won't even have to think about it!

One of the greatest advantages of naming conventions is in maintenance. You will inevitably spend a proportion of time maintaining code, and not necessarily your own code. If a standard set of conventions has been used, it makes your job so much easier. You will automatically know where global variables are stored, what type variables are, and what their scope is, and the chance of introducing errors is automatically reduced. If you follow this procedure, then it benefits others who have to maintain your code. No one likes maintenance, we all want to write cool new apps, so the quicker and more efficient you can make the process the better.

Important 

The really important thing to remember is consistency. Whichever style you choose, you should be consistent with its use. Don't think that just because you are writing a small program or a single procedure that naming conventions have no place. If you are going to use a style, then use it everywhere.