• B
  • Visual Basic 5 Naming Conventions
    • TIP
    • Module, Class, Function, and Procedure Headers
    • Listing B.1. A module, form, VBScript, or Active Server Page header.
    • Listing B.2. A class page header.
    • Listing B.3. A procedure or function header.
    • Control Naming Conventions
    • Other Naming Conventions
      • Variable Scope
      • Variable Naming Conventions
      • Data-Access Naming Conventions

-B-

Visual Basic 5 Naming Conventions

With Visual Basic 5, VBScript, and Active Server Page development, it is more important than ever for you to develop naming standards and conventions for applications, components, and Web pages. If you are a single developer or you work in a team with several other developers, naming conventions will make your code and script files easier to read and maintain. By using the same prefixes for objects and variables, it will be easier for you and your colleagues to read through code and script files without having to refer back to a variable or object to determine the type. I recommend using standard Visual Basic naming conventions published by Microsoft in the Visual Basic 5.0 Programmers Guide in the section "Visual Basic Coding Conventions." Many programmers and software shops have made the published Microsoft standards their own, so you will find moving from job to job easier. Regardless of whose naming standards you or your organization adopts, make sure that you use some sort of naming standards; don't code without them!

---

TIP: Always use many, many comments in your script files and code. It makes life so much easier for you and anyone who has to maintain your code

---

Module, Class, Function, and Procedure Headers

When you develop Visual Basic modules, you should make sure that each module includes a header with an overview of the module's use. You can use the same type of header in a Visual Basic form, a VBScript, a file, or a Active Server Page. Listing B.1 shows an example of these headers.

Listing B.1. A module, form, VBScript, or Active Server Page header.

`*******************************************************
`               Sams Publishing
`*******************************************************
`
`Purpose:
`
`
`*******************************************************
`History:
`   Mark Spenik     10/31/96
` Initial Release
`
`*******************************************************

A class module should have a header as well. Also, make sure that you document the class so that descriptions can be viewed by using the Object Browser. Listing B.2 shows a class header.

Listing B.2. A class page header.

`***************************************************************************
`               Sams Publishing
`
`Class:
`Purpose:
`
`  Notes:
`
`History:
`   Mark Spenik     05/28/96
` Initial Release
`

`***************************************************************************

Procedures and functions should have a descriptive header with less detail, as shown in Listing B.3.

Listing B.3. A procedure or function header.

`Description:
`Input Parameters:
`Outputs:
`History

Control Naming Conventions

The naming conventions listed in Table B.1 are for common ActiveX controls. These naming conventions are suggested by Microsoft. I have found them to be widely accepted in the industry, so I recommend that you use them. You can find a similar detailed list in the Visual Basic Developers Guide that ships with Visual Basic 5. When using the naming standards, make sure that you choose a descriptive name that describes the control (spell it out). The prefix for a textbox is txt, for example. If you will have a textbox that will hold a person's first name, a good name for the control would be txtFirstName--not txtfrstname.

Table B.1. Naming Prefixes for Commonly Used Controls.

Control	Prefix
Checkbox	chk
Combo box	cbo
Command button	cmd
Common dialog box	dlg
Data control	dat
Data-bound combo box	dbcbo
Data-bound grid	dbgrd
Data-bound listbox	dblst
Form	frm
Frame	fra
Graph	gra
Image	img
Label	lbl
Listbox	lst
OLE	ole
Picture	pic
Progress bar	prg
Report	rpt
Textbox	txt
Timer	tmr
Toolbar	tlb

You should use naming conventions as well for data-access objects and variables. I have not seen the Microsoft standards for variables and data-access objects as widely adopted as the control standards, so this section takes a look at a few naming conventions. Again, regardless of the naming standard, it is important that you use one and use it consistently.

The most common naming standard to help a programmer determine the scope of a variable is to use the first letter of the variable name as the scope. A global variable starts with a lowercase g, a module-level variable starts with a lowercase m, and local variables have no prefix. (Table B.2 provides some examples.)

I like the variable naming standards provided by Microsoft. I think they are consistent with the naming conventions of controls, because they use a three-digit prefix to name the variable. I have been beaten up a few times in standards meetings by other programmers who wanted a simpler variable naming convention, though. Table B.2 lists the variables, the Microsoft- suggested standard, and a common standard I have seen used quite frequently.

Table B.2. Variable Naming Nonventions.

Type	Microsoft Standard	Other
Boolean	bln	bool
Currency	cur	c
Date	dtm	dtm
Double	dbl	d
Integer	int	i
Long	lng	l
Object	obj	o
String	str	s
Variant	vnt	v

An integer status value might have the following names, for example (notice the use of the scope prefix):

• Global integer: gintStatus

• Module integer:mintStatus

• Local integer: intStatus

I have seen more naming conventions in data-access objects (DAOs) than in any of the other areas described here. I have seen some companies use the prefix ds to represent a DAO dynaset and ss to represent a DAO snapshot. I prefer standards that can be used by DAO, Remote Data Objects (RDOs), and Active Data Objects (ADOs) for data-access objects. Table B.3 lists some common prefixes for data-access objects. In the Microsoft DAO column, Yes means that the standard is a Microsoft-suggested DAO standard; No means that it is not a Microsoft standard for DAO. You can use the naming conventions in this table for DAO, RDO, and ADO.

Table B.3. Data-access Naming Conventions.

Data Object	Prefix	Microsoft DAO
Connection	cnn	No
DAO QueryDef/	qry	Yes
RDO query object
DAO Recordset	rec	Yes
Database	db	Yes
Resultset	rst	No