Establishing Good Habits in Coding

Getting the job done is rarely your only goal when customizing your database using VBA code. From the very beginning, you should think like a professional developer by writing readable code that's easy to follow with little effort. We offer three recommendations:

• Name variables and objects consistently.

• Indent your code to show structural flow.

• Comment your code so you can remember what your code does later because you will forget. Besides, you might not be the one updating your code.

Using a Naming Convention

As you write VBA code, you'll create variables and objects, which need a name. You can name them any way you please, but we recommend that you use a consistent convention.

Youll learn how to create and use variables in "Declaring Variables and Constants" in Chapter 3 (p. 33) You'll learn more about objects in Chapter 8 (p. 113).

A naming convention is a set of rules that determine the names of variables and objects. Your company or organization may have a convention, and if that's the case, you'll apply those rules. If you have to choose one, don't let the task overwhelm you because the key is to consistently apply a convention any convention, even if it's your own.

A good convention will indicate the type of object or variable you're creating. A fairly common form using the following syntax:

 classObjectName 

where class is a three-letter prefix that identifies the type of object or a variable's data type, and ObjectName is a purposeful, descriptive name. Notice the strange letter case in the form:

• class is lowercase.

• ObjectName uses camel or title case the first letter of each word is uppercase.

Also, notice that the name contains no spaces.

Throughout this book we'll work with a common convention that's based on the Hungarian convention. This convention adheres to the preceding rules. In addition, we'll use what's known as the natural naming system, whereby the object and variable names identify their purpose or the data they contain.

Tables 2.2 and 2.3 list the most common prefixes. Neither list is complete by any means, but these are the tags that we'll use throughout this book and that you'll probably encounter most often.

Table 2.2. Object Tags

Access Object	Prefix
table	tbl
query	qry
form	frm
report	rpt
check box	chk
combo box	cbo
command button	cmd
label	lbl
list box	lst
option button	opt
subform/subreport	sub
text box	txt

Table 2.3. Variable Tags

Data Type	Tag
byte	byt
integer	int
single	sng
long integer	lng
double	dbl
text	str
currency	cur
date/time	dtm
Boolean	boo

At first, you might wonder what all the fuss is about, but as you produce more code, you'll begin to appreciate a consistent naming scheme. Most importantly, you can tell at a glance what type of variable or object you're dealing with, and that can mean a lot when you're debugging or maintaining code.

Indenting Your Code

You may have noticed that the code in the earlier example is indented. This is another good habit you should establish early because the indentations help indicate the code's structural flow.

For example, each line is our earlier sample procedure (refer to Figure 2.8) in indented two spaces from the procedure's name and End statements. These indents simply make it easier to read the code. After awhile you'll indent code automatically.

You can insert an indent using the VBE's interface. To do so, highlight the code in the module, and then choose Edit, Indent or Outdent, appropriately. The Indent command enters one tab; Outdent removes a tab. By default, these tabs are equal to four characters.

TIP

Indents are a clue to the code's structure and flow. Another way to distinguish individual steps is to add a blank line at logical points. Whether you do so is up to you, but you'll probably find that a blank line helps you locate specific sections of code much quicker.

Commenting Your Code

Adding comments that describe your code's purpose is always a good idea. To add a comment, simply preface it with the apostrophe character ('), as you did in earlier in the chapter:

 Public Sub OpenClientForm()   ' Open the client form   DoCmd.OpenForm "Clients"   Debug.Print "The form is open" End Sub 

Each procedure should have an introductory comment that describes the procedure's purpose. Code composed of many lines and tasks will require more comments. There's a knack that comes to knowing just when and just what to say, but here are a few guidelines that should help:

• Be as succinct as possible.

• Be as descriptive as possible.

• Use grammatically correct sentences and phrases.

• Use punctuation when appropriate.

• Avoid comments that simply restate the code.

• Comment passed arguments if attributes aren't obvious in the code.

• Comment revisions who made the change, when it was made, and why. (Not all developers include these comments.)

• Write comments as you write the code and the task and any problems worth commenting are still clear in your mind.

Another commenting format places comments in line and to the right of the actual code. We won't use this format in this book, but you'll probably encounter it when reviewing existing code.

The Edit toolbar contains commenting tools that can help you comment or uncomment a large block of code. To illustrate, display the toolbar by choosing View, Toolbars, Edit. Then, highlight a block of code and click Comment Block on the Edit toolbar. Figure 2.16 shows the results of commenting an entire procedure with one quick click. Click Uncomment Block on the Edit toolbar to remove comments.

Figure 2.16. Quickly comment out an entire procedure.