Establishing Good Habits in Coding

 < 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:

  • 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.

graphics/02fig16.jpg


     < Day Day Up > 


    Automating Microsoft Access with VBA
    Automating Microsoft Access with VBA
    ISBN: 0789732440
    EAN: 2147483647
    Year: 2003
    Pages: 186

    Similar book on Amazon

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net