|< Day Day Up >
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:
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:
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:
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.
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.
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:
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.
|< Day Day Up >