Naming Conventions

Using a system of naming conventions is one of the easiest things you can do to make your code self-documenting. Using naming conventions means doing two things: using descriptive names for procedures and variables; and using prefixes that describe the data type, scope, and function of the procedure or variable.

a Assigning descriptive names to procedures and variables doesn't have to mean that names e will be long and complicated. All that is required is that the name indicate roughly what the w procedure is used for or the type of information represented by the variable. Mixed case should be used to make the name easier to read, such as AddTask, FormatTableForPrinting, or TaskName.

Prefixes can be used to describe many things about the procedure or variable, such as type, scope, and function. In fact, there is a commonly used system of prefixes for Visual Basic, examples of which are shown in Tables 30-3 through 30-6.

Table 30-3 shows prefixes that describe data types, such as strTaskName. Table 30-3. Data Types

Prefix

Type of Variable

bln

Boolean

str

String

int

Integer

lng

Long

obj

Object

var

Variant

Table 30-4 shows prefixes that describe controls, such as cmdOK and txtTaskName.

Table 30-4. Controls

Prefix

Type of Control

chk

Check box

cmd

Command button

frm

Form

lbl

Label

lst

List box

mnu

Menu

opt

Option button

txt

Text box

Table 30-5 shows prefixes that describe scope, such as the local variable strTaskName and the

global gstrTaskName.

Table 30-5. Scope

Prefix

Type of Scope

no prefix

Procedure (local)

m

Module (private)

g

Global (public)

Table 30-6 shows prefixes that describe function, such as c_gstrTaskName for a global String a.

constant and a_intTaskList to describe a local Integer array. o

Table 30-6. Function

Prefix

Type of Function c

A constant a

An array o

3"

The following example of a sub and a function, taken from the discussion on procedures earlier in this chapter, illustrates the use of prefixes and descriptive names:

Function strNewTask(strName As String, intBefore As Integer) As String ActiveProject.Tasks.Add strName, intBefore

If ActiveProject.Tasks(intBefore).Name = strName Then strNewTask = "Success!"

Else strNewTask = "Failed to create task!" End If End Function

Sub AddTask()

MsgBox strNewTask("Write chapter", 3) End Sub

Suppose that you were reading the code for the first time, the two procedures weren't right next to each other, and all you saw was AddTask. Suppose further that AddTask was written as follows:

Sub AddTask()

MsgBox strNewTask(strTaskName, intTaskNum) End Sub

Because of a consistent pattern of naming conventions, you can infer a lot about strNewTask, including:

• strNewTask is a function.

• Functions use a prefix, and subs do not.

• The function returns a String.

• The prefix str denotes a String variable.

• The function takes at least two arguments.

• You do not know, however, if either argument (or both) is optional.

• The first argument requires a String representing the name of a task.

• The prefix str denotes a String variable, and the name of the variable indicates the type of information it contains.

• The second argument requires an Integer representing the position of the new task in the task list.

The prefix int denotes an Integer variable and the name of the variable indicates the type of information it contains.

Forever Motivated

Forever Motivated

I can show you how to get motivated for ANYTHING. Yes, whether it's dealing with difficult relationship, health, or any other issues. Here's How It Works. Finding the motivation to do something difficult comes from within. No matter what anyone else says- you've got to know how to do it for yourself. The thing is- NOBODY teaches you how to motivate yourself, right? That's not exactly something we're taught in school these days. Luckily, after a TON of trial and error I've simplified the process.

Get My Free Ebook


Post a comment