Table of Contents

1 Preface............................................................................................................................ 1
2 Introduction.................................................................................................................... 2
3 Objectives....................................................................................................................... 3
3.1 Minimal Coding Conventions............................................................................................3
4 Design Guidelines........................................................................................................... 4
5 User Interface Standards................................................................................................. 6
5.1 Menus................................................................................................................................6
5.2 Controls.............................................................................................................................6
5.2.1 CommandButton.........................................................................................................6
5.2.2 TextBox......................................................................................................................7
5.2.3 Checkbox control........................................................................................................7
5.2.4 Frame control..............................................................................................................8
5.2.5 OptionButton control..................................................................................................8
5.2.6 ComboBox control......................................................................................................8
5.2.7 ListBox control...........................................................................................................9
5.2.8 ListView control.........................................................................................................9
5.2.9 TreeView control........................................................................................................9
5.2.10 Label...........................................................................................................................9
5.2.11 Tab control:...............................................................................................................10
5.2.12 TabStrip Control.......................................................................................................10
5.2.13 Form.........................................................................................................................10
5.3 Menu Help - About Box...................................................................................................10
5.4 Message Box....................................................................................................................11
6 Naming Conventions..................................................................................................... 12
6.1 Control Naming Convention............................................................................................12
6.2 Constant and Variable Naming Conventions.....................................................................13
6.2.1 Variable/Constant Scope Prefixes..............................................................................14
6.2.2 Constants..................................................................................................................14
6.2.3 Variables...................................................................................................................15
6.2.4 Constant/Variable Data Types...................................................................................15
6.2.5 Use the following prefixes to indicate a variable's data type.......................................15
6.2.6 Descriptive Variable and Procedure Names................................................................15
6.2.7 User-Defined Types..................................................................................................15
6.3 Qualifiers.........................................................................................................................16
6.4 Function and Subroutine..................................................................................................16
6.5 Menus..............................................................................................................................17
7 Programming Standards................................................................................................ 18
8 General Standards and Guidelines................................................................................. 20
1 Preface

This document contains the GUI Standards that should be used while programming in
Visual Basic environment. It has been divided into several topics. The glossary at the end
explains the special terminology used in the document.

Intended Reader

This document is targeted at readers/developers with prior programming experience in

Visual Basic.
2 Introduction
The traditional application development process can be broken into three distinct steps:
writing, compiling, and testing code. Unlike traditional languages, Visual Basic uses an
interactive approach to development, blurring the distinction between the three steps.
With most languages, if one makes a mistake in writing the code, the compiler catches the
error when one starts to compile the application. One must then find and fix the error and
begin the compile cycle again, repeating the process for each error found. Visual Basic
interprets the code as it is entered, catching and highlighting most syntax or spelling errors
on the fly. It's almost like having an expert watching over one’s shoulder as the code is
entered.
In addition to catching errors on the fly, Visual Basic also partially compiles the code as it
is entered. When ready to run and test the application, there is only a brief delay to finish
compiling. If the compiler finds an error, it is highlighted in the code. One can fix the
error and continue compiling without having to start over.
Because of the interactive nature of Visual Basic, one find oneself running the application
frequently as it is develop. This way one can test the effects of one’s code as one works
rather than waiting to compile later.
Irrespective of the facilities provided by the Visual Basic Development Environment, it is
necessary to establish a regimen and shape every developer’s approach to designing
applications and writing code. This we do it by defining certain standards and guidelines.
Also Visual Basic 6.0 has undergone subsequent changes since its previous release of
Version 5.0. New concepts such as ADO (ActiveX Data Objects) for database access and
new and enhanced controls such as the Coolbar, DateTimePicker, DataGrid, DataList, etc
make necessary to bring in some standardisation in representing and coding them in our
applications
This document gives the suggested GUI standards that should be used while designing the
forms in Visual basic. First the different naming conventions for naming different
variables, controls, etc. are stated. Then there are different guidelines, which can be
followed during programming in Visual Basic.
3 Objectives
Coding standards and conventions are programming guidelines that focus not on the logic of the
program but on its physical structure and appearance. They make the code easier to read,
understand, and maintain. Coding conventions can include:

 User interface standards for designing screens, desktops and menus.

 Naming conventions for objects, variables, and procedures.

 Standardized formats for labeling and commenting code.

 Guidelines for spacing, formatting, and indenting.

In the sections that follow, each of these areas is discussed, along with some examples of good
usage.
The main reason for using a consistent set of coding conventions is to standardize the structure and
coding style of an application so that writer of code and others can easily read and understand the
code.
Good coding conventions result in precise, readable, and unambiguous source code that is
consistent with other language conventions and as intuitive as possible.

3.1 Minimal Coding Conventions

A general-purpose set of coding conventions should define the minimal requirements necessary to
accomplish the purposes discussed above, leaving the programmer free to create the program’s
logic and functional flow.
The object is to make the program easy to read and understand without cramping the
programmer’s natural creativity with excessive constraints and arbitrary restrictions.
To this end, the conventions suggested in this document are brief and suggestive. They do not list
every possible object or control, nor do they specify every type of informational comment that
could be valuable. Depending on the project and the organization’s specific needs this document
can be enhanced to cater to future needs.
4 Design Guidelines
The use of controls should be standardised depending upon the input/output scenarios.
Following is a table, which lists the commonly encountered input/output scenarios and the
respective control to be used.

Sr. Input / Output Scenario Control to choose Component

No.
1. Date DTPicker Microsoft Windows
Common Controls-2 6.0
2. String Text / Label Not applicable
3. Formatted String / MaskEdBox Microsoft Mask Edit
Formatted Numeric Control 6.0
4. List of Values Number of Drop Down Combobox Not applicable
Values > 3 and editable

5. Field to be displayed is a Drop Down ListBox Not applicable

database field having
foreign key reference
6. List of Values Values > Drop down ListBox Not applicable
3, Non Editable
7. Fields that contain yes/no CheckBox Not applicable
values
8. Fixed Optional Values OptionButton Not applicable
Values > 1 and <= 3

9. Database access Adodc Microsoft ADO Data

Control 6.0 (OLEDB)
(Application dependent)
10. To inform the user of StatusBar Microsoft Windows
various properties such as Common Controls-2 6.0
the name of the table
being edited, its creation
date, and the date of the
last update and some
brief context sensitive
help when editing records
of a database. Also used
provide context sensitive
help when accessing
menus and controls on
the form.
11. To functionally isolate TabControl Microsoft Windows
controls on a form Common Controls 6.0
12. View/Update data from DataGrid Microsoft DataGrid
database table in a tabular Control 6.0 (OLEDB)
form
13. View/Update data from Hierarchical Flex Grid Microsoft Hierarchical
database tables FlexGrid Control
implementing a Master- (Application dependent)
6.0(OLEDB)
Detail relationship
14. Graphical interface for Toolbar Not Applicable
the user to access an
application's most
frequently used functions
and commands.
5 User Interface Standards
5.1 Menus
Following are the standards to be followed when designing Menus.
1. No more than 3 levels of sub menus should be designed per main menu.
2. Menu item should be followed by “…” if it pops a dialog.
3. Each menu item should have an access key, i.e. underlined character in the caption of the
menu item.(i.e. File)
4. Use of separator should be done to distinguish between logical group of menu items
5.2 Controls
The following section lists standard property values for controls commonly used in every
Visual Basic application. Here, distance between two controls is specified in terms of Form
twips and this distance should be 165 twips.
The font used for each control should be MS Sans Serif.
The font Style should be Regular.
The font Size should be 10.

5.2.1 CommandButton

Default Buttons: These are command buttons that would virtually appear on every form/dialog
box/message box. These are typically the Ok, Cancel and Help buttons. Following are the
standards for such buttons:
1. The default buttons, OK, Cancel, and Help should not have access keys. These three
buttons should be bottom right aligned, with the Help button following the Cancel button
and Cancel button following the OK button.
2. If the dialog box requires only Close button instead of OK and Cancel buttons, then
Close and Help button should be placed in bottom right corner with Help button
following Close.
3. For the OK button caption, both ‘O’ and ‘K’ should be upper case.
4. For the OK button, the DEFAULT property should be set to TRUE.
5. For the Cancel button, the CANCEL property should be set to TRUE.
6. <F1> key should be the shortcut key for Help.
7. Size of the buttons: 1095 x 375 Twips.
8. The caption of the button should be centre aligned.

User Defined Buttons: These are customised buttons to serve the application’s needs. Following
are the standards to be followed for such buttons:
1. Buttons in all the forms, having the same caption, should have the same access keys. E.g.
If “Add” button has access key “A” in one dialog box, then all dialog boxes that have an
'Add' button should have the same access for it.
2. Two buttons placed horizontally or vertically adjacent to each other should have a
distance of 165 twips between them.
3. Two different horizontal or vertical groups of buttons can be placed at a distance
convenient as per application. This distance should not be less than 495 twips.
4. All vertically adjacent buttons should be left/right aligned, all horizontally adjacent
buttons should be top/bottom aligned.
5. Use default Foreground and Background colours.
 6. If the button caption length exceeds the width of the button, then the button width should
be such that there is a distance of 270 twips between the left of the caption and the left
border of the button. Similarly there should be a distance of 270 twips between the right
of the caption and the right border of the button.
7. The Visible property should be set.
8. The Tabstop property should be set.
9. The TabIndex property should be set.
10. The Tool tip property should be set.

5.2.2 TextBox

1. Height of the single line text box should be 315 twips.

2. If number of characters to be displayed in the textbox is less than or equal to 40, then the textbox
should have its multi-line property set to false.
3. If number of characters to be displayed in the textbox is greater than 40, then the textbox should
have its multi-line property set to true. Also its height should be a multiple of 315 twips
multiplied by the number of lines to be displayed
4. The TEXT property should be the default value if one exists or should be left empty.
5. Distance between the controls will be the same as in case of button.
6. To avoid changing the Text Box contents, it should be ‘locked for edit’.
7. The Alignment property should be set to the following depending on the data-type it holds:
Numeric - Right Aligned (Multi-line property should be set to true for this to work)
Date - Left
Character - Left
8. If the user input to a text box is fixed and in a small range, (e.g. 0-9) then use a dropdown combo
box instead of the text box.
9. Use default Foreground and Background colours.
10. Length of the text box :
10.1 If the maximum number of characters, which can be displayed in the text box, is known, the
length of the text box should not be less than (255 twips) x (the maximum number of
characters displayed). This is because 255 twips is the space required for the widest
character “W” to be displayed completely.
10.2 The actual length of the text box should be decided depending on various factors like
10.2.1 Distance of the text box from the dialog box borders, and from the other controls.
10.2.2 Lengths of the other controls placed above and below the text box.
10.2.3 Length of other text box with similar functionality.
11. Some mandatory properties that should be set are:
11.1 A meaningful Name
11.2 The Visible property should be set.
11.3 The Tabstop property should be set.
11.4 The TabIndex property should be set.
11.5 The Border property should be set.
11.6 The Multiline property should be set if the text box is to cater to multiple lines.
12. The maximum number of lines displayed by a multi-line textbox should be 6. If the number of
lines to be displayed exceeds limit, then the scroll bar property should be set to ‘Vertical’.

5.2.3 Checkbox control

1. Some mandatory properties of the check box that should be set are:
1.1. A meaningful Name.
1.2. A meaningful Caption.
1.3. The Visible property should be set.
1.4. The TabIndex property should be set.
1.5. The Tabstop property should be set.
1.6. The Alignment should be set to “left”.
5.2.4 Frame control
1. The Frame should not have a shortcut.
2. The frame should be drawn before the controls are placed within them.
3. The Frame caption should not have leading or trailing spaces.
4. The caption of the frame should always be left-aligned, which is default.
5. Distance of the controls in a frame from the borders of the frame should be 165 twips. When the
Frame control is laid out on the form it is not possible to view the underlying form grids, hence it
is recommended to use the judgement through keyboard to achieve the same above specification.
6. The General section of the Frame control properties should have the following properties set :
6.1. A meaningful Name.
6.2. A meaningful Caption with no short-cut key defined.
6.3. The Visible property should be set.
6.4. The Tabstop property should not be set.
6.5. The TabIndex property should not be set.

5.2.5 OptionButton control

1. If two or more option buttons are used as a group, they should be placed in a frame.
2. Height should be the default and there should be no distance between two vertically adjacent
option buttons.
3. Two items in a group of option buttons should not complement each other. e.g. One option
button with it’s caption as “Ignore” and the other with it’s caption as “Do not ignore”. Use a
single Checkbox in such cases.
4. A group of option button must have the option button that represents the default value selected.
i.e. one option button from the group must be checked.
5. Some mandatory properties that should be set for the option button are as follows :
5.1. A meaningful Name.
5.2. A meaningful Caption.
5.3. The Visible property should be set.
5.4. The Alignment should be set to “left”.

5.2.6 ComboBox control

1. Height of the combo box should be default, viz. 315 twips.
2. If the maximum length of the string that can be contained in the combo box list can be judged,
the length of the combo box should not be less than this length. It’s actual length can be decided
by adopting a strategy similar to the one described in the point 10.1 of section 7.2.2.
3. The number of elements shown in the drop-down list at a time should not be more than 8.
4. Following is alignment of field depending on data-type the combo box holds:
Numeric - Right Aligned (Multi-line property should be set to true for this work)
Date - Left
Character - Left
5. The default selected value in combo box list should be shown in the edit box of the combo box.
6. The drop-down list of items should be sorted.
7. The drop-down list can go beyond the height of the dialog box.
8. Some mandatory properties that should be set for the ComboBox are as follows :
8.1. A meaningful Name.
8.2. The Visible property should be set.
8.3. The TabIndex property should be set.
8.4. The Tabstop property should be set.
8.5. The Sorted property should be set.

5.2.7 ListBox control

1. The width of the listbox should be set such that the use of horizontal scroll bars is avoided as far
as possible.
2. The height of the listbox should be a multiple of the individual item height. No item in the list
box should be half-visible.
3. Some mandatory properties that should be set for the ListBox are as follows :
3.1. A meaningful Name.
3.2. The Visible property should be set.
3.3. The TabIndex property should be set.
3.4. The Tabstop property should be set.
3.5. The Sort property should be set.
3.6. The IntegralHeight property should not be set if the Listbox control is intended to show
incomplete items.

5.2.8 ListView control

1. If the ListView is utilized as a report view, the column heading should be fully visible. No
abbreviations to be used for headings, unless used in the business terminology.
2. In case of large icon view, the size of the ListView control should be such that no icon is half-
displayed.
3. For the Report view of the ListView control, if sorting is not implemented, the column-heading
buttons should not have the button press effect.
4. Some mandatory properties that should be set for the ListView are as follows :
4.1. A meaningful Name.
4.2. The Visible property should be set.
4.3. The Tabstop property should not be set.
4.4. The BorderStyle property should be set.
4.5. If no sorting is implemented, “Sort” property should be set to none.

5.2.9 TreeView control

1. The TreeView control should have bitmaps associated with every element of the tree.
2. The bitmap associated with an element of the tree control should change for the currently selected
tree item.
3. The style property of the property pages must be set to 7 – tvwTreelinesPlusMinusPictureText.
4. The mandatory properties that should be set for the TreeView are as follows :
4.1. A meaningful Name.
4.2. The Visible property should be set.
4.3. The Tabstop property should be set.

5.2.10 Label
1. The Labels associated with single line text box control and combo box control should be placed
at the left of the edit control.
2. For Tree control, Listbox control, Listview control and for multi-line Textbox control, it should
also be placed beside the associated control.
3. If the label is associated with some control, then the access key for that control should be defined
as part of the static text, and that control should follow the label in the tab order.
4. If a label is not associated with any control, then it should not have any access key.
5. The label should be in the form of a statement and not in the form of a command.
Example: the label for name edit box should be “User Name“ and not “Enter User Name“.
6. The text in the Label should be self-explanatory and not misleading.
7. Redundancy should be avoided in the case of Form caption, Frame caption and the Label.
8. The mandatory properties that should be set for the Label are as follows:
8.1. A meaningful Name.
8.2. A meaningful Caption with the access key.
8.3. The Autosize should be set to “True”. When Autosize is set to True, the label should not be
resized.
8.4. The Visible property should be set.
8.5. The Tabstop property should not be set.
 8.6. The Alignment property should be set to “Left”.

5.2.11 Tab control:

1. Whenever the controls in the dialog box can be classified into separate functional groups, then tab
control should be used for this dialog box.

5.2.12 TabStrip Control

1. A TabStrip acts like the dividers in a notebook or the labels on a group of file folders. By using a
TabStrip control, you can define multiple pages for the same area of a window or dialog box in
your application.

5.2.13 Form
1. Every form should have balanced distribution of controls.
2. Validation of inputs should be performed only on OK button press event, or in the case of tab
change event (If tab control is used.)
3. Dynamic show-hide of controls on some event should be avoided. Such controls should be
enabled or disabled instead.
4. The default focus should be set to a required control.
5. Every Form must have a Name
6. Every form must have a Caption. The Caption should be as follows
<Application Name>: <Description of the Form>
7. The default Font should be used.
8. The default Font Size should be used.
9. While designing forms, ensure the desktop screen size is set to a resolution of 800x600.
10. The “HelpContextId” property should be set.
11. Position of the form should be screen centred.
12. The form should be suitably sized when the number of fields on it is too few.
13. In the case of multiple text boxes placed one below the other on the form
13.1 All the labels should be left aligned with respect to each other.
13.2 All the text boxes should be left aligned with respect to each other.
13.3 The alignments done in 15.1 and 15.2 should be done independent of each other.
14. If border style of a form is set to resizable, code should be written so that the controls in it are
rearranged every time the form is resized at runtime.
15. The tab sequence should be left to right and top to bottom.

5.3 Menu Help - About Box

1. Every application should have an “About Application” box, popped from “Help | About”
menu item
2. The “About Application” Box of the application should contain the following
 Caption should be set to “About “ + <Application Name>
 The body of about box should contain:
 Application Name
 Application Icon,
 Version number
 Date of release
 Copyright notice (optional)
 Buttons “System Info” and “OK”

5.4 Message Box

The Message Box is used to get yes or no responses from users, and to display brief messages, such
as errors, warnings, or alerts in a dialog box. After reading the message, the user chooses a button to
close the dialog box. When such a response is desired the msgbox function should be used for this and
message that is displayed should be apt to the situation for which the message box is displayed. The message
box have the following characteristics:
1. The message box should contain an appropriate icon such as warning, exclamation, critical, etc.
2. The message that is displayed should be at two levels – business and technical.
3. The message box should give the user the appropriate combination of buttons to respond with.
4. After displaying the validation error message, the control which has the error should have the
focus and its contents should be selected.
5. Similar error messages should have similar language.
6. If the message is a statement, it should have “OK” and “Cancel” or only “OK” button depending
on the context, with default focus set to “OK” button.
7. Messages pertaining to loss of data, deletion etc. should have “Yes” and “No” buttons in the message box
with the default focus set to 'No' button.
Example: When updating the Client table of a bank’s database, an error occurs – in this situation you
will display a message box with the “Critical” icon. The business level message in the message box
should be “Update on Client table failed”. The technical message may be “Error connecting to SQL
Server. Error Number: 1345”. Also the button options would be “Abort”, “Retry” and “Ignore”.
6 Naming Conventions
6.1 Control Naming Convention
The following table gives the commonly used Visual Basic Controls and the their respective
prefixes.

Control type Prefix Example

3D Panel pnl pnlGroup
ADO Data ado adoBiblio
Animated button ani aniMailBox
Check box chk chkReadOnly
Combo box, drop-down list box cbo cboEnglish
Command button cmd cmdExit
Common dialog dlg dlgFileOpen
Communications com comFax
Control (used within procedures
ctr ctrCurrent
when the specific type is unknown)
Data dat datBiblio
Data-bound combo box dbcbo dbcboLanguage
Data-bound grid dbgrd dbgrdQueryResult
Data-bound list box dblst dblstJobType
Data combo dbc dbcAuthor
Data grid dgd dgdTitles
Data list dbl dblPublisher
Data repeater drp drpLocation
Date picker dtp dtpPublished
Directory list box dir dirSource
Drive list box drv drvTarget
File list box fil filSource
Flat scroll bar fsb fsbMove
Form frm frmEntry
Frame fra fraLanguage
Gauge gau gauStatus
Graph gra graRevenue
Grid grd grdPrices
Hierarchical flexgrid flex flexOrders
Horizontal scroll bar hsb hsbVolume
Image img imgIcon
Image combo imgcbo imgcboProduct
ImageList ils ilsAllIcons
Label lbl lblHelpMessage
Lightweight check box lwchk lwchkArchive
Lightweight combo box lwcbo lwcboGerman
Lightweight command button lwcmd lwcmdRemove
Lightweight frame lwfra lwfraSaveOptions
Lightweight horizontal scroll bar lwhsb lwhsbVolume
Lightweight list box lwlst lwlstCostCenters
Lightweight option button lwopt lwoptIncomeLevel
Lightweight text box lwtxt lwoptStreet
Lightweight vertical scroll bar lwvsb lwvsbYear
Line lin linVertical
List box lst lstPolicyCodes
ListView lvw lvwHeadings
MAPI message mpm mpmSentMessage
MAPI session mps mpsSession
MCI mci mciVideo
Menu mnu mnuFileOpen
Month view mvw mvwPeriod
MS Chart ch chSalesbyRegion
MS Flex grid msg msgClients
MS Tab mst mstFirst
OLE container ole oleWorksheet
Option button opt optGender
Picture box pic picVGA
Picture clip clp clpToolbar
ProgressBar prg prgLoadFile
Remote Data rd rdTitles
RichTextBox rtf rtfReport
Shape shp shpCircle
Slider sld sldScale
Spin spn spnPages
StatusBar sta staDateTime
SysInfo sys sysMonitor
TabStrip tab tabOptions
Text box txt txtLastName
Timer tmr tmrAlarm
Toolbar tlb tlbActions
TreeView tre treOrganization
UpDown upd updDirection
Vertical scroll bar vsb vsbRate

Note: RDO and DAO must not be used. Only ADO usage is permissible.

6.2 Constant and Variable Naming Conventions

Constants and variables require well-formed naming conventions. This section lists
conventions for constants and variables supported by Visual Basic. It also discusses the
issues of identifying data type and scope.
Constant and Variables should have the following structure:
<scope><type><body><qualifier><suffix>

Variables should always be defined with the smallest scope possible. Global (Public)
variables can create enormously complex state machines and make the logic of an application
extremely difficult to understand. Global variables also make the reuse and maintenance of
the code much more difficult.
 Variables in Visual Basic can have the following scope:

Scope Declaration Visible in

'Private' in procedure, sub, or The procedure in which it is
Procedure-level
function declared
'Private' in the declarations
Every procedure in the form or
Module-level section of a form or code module
code module
(.frm, .bas)
'Public' in the declarations
Global Everywhere in the application
section of a code module (.bas)

In a Visual Basic application, global variables should be used only when there is no other
convenient way to share data between forms. When global variables must be used, it is good
practice to declare them all in a single module, grouped by function. Give the module a
meaningful name that indicates its purpose, such as Globals.bas.

With the exception of global variables (which should not be passed), procedures and functions should operate
only on objects passed to them. Global variables that are used in procedures should be identified in the
declaration section at the beginning of the procedure.

6.2.1 Variable/Constant Scope Prefixes

As project size grows, so does the value of recognizing variable scope quickly. A one-letter
scope prefix preceding the type prefix provides this, without greatly increasing the size of
variable names.

Scope Prefix Example

Global g gstrUserName
Module-level m mblnCalcInProgress
None or t (use one
Local to procedure dblVelocity
consistently)
Static st stintCount
Variable passed by value (parameter
v vlngTemperature
for a procedure)
Variable passed by reference
r rintPressure
(parameter for a procedure)

A variable has global scope if it is declared Public in a standard module or a form module. A variable
has module-level scope if declared Private in a standard module or form module, respectively.
Note: Consistency is crucial to productive use of this technique; the syntax checker in Visual Basic
will not catch module-level variables that begin with "p."

6.2.2 Constants
The body of constant names should be in upper case with underscore separating each word.
Although standard Visual Basic constants do not include data type and scope information,
prefixes like i, s, g, and m should be used as they are very useful in understanding the value and
scope of a constant. The constant names should be a Noun. For constant names, follow the same
rules as variables.
Example:
mintUSER_LIST_MAX 'Max entry limit for User list
'(integer value,local to module)
gstrNEW_LINE 'New Line character
'(string, global to application)
6.2.3 Variables
Declaring all variables saves programming time by reducing the number of bugs caused by typos (for
example, aUserNameTmp vs. sUserNameTmp vs. sUserNameTemp). On the Editor tab of the
Options dialog, check the Require Variable Declaration option. The Option Explicit statement
requires that all the variables in the Visual Basic program is declared explicitly.
Variables should be prefixed to indicate their data type. Optionally, especially for large programs, the
prefix can be extended to indicate the scope of the variable.

6.2.4 Constant/Variable Data Types

6.2.5 Use the following prefixes to indicate a variable's data type.

Data type Prefix Example

Array arr arrMatrixElement
Boolean bln blnFound
Byte byt bytRasterData
Collection object col colWidgets
Currency cur curRevenue
Date (Time) dtm dtmStart
Double dbl dblTolerance
Error err errOrderNum
Integer int intQuantity
Long lng lngDistance
Object obj objCurrent
Single sng sngAverage
String str strFName
User-defined type udt udtEmployee
Variant vnt vntCheckSum
Connection con cnnBiblioDb
Command cmd cmdUpdateAuthors
Field fld fldAuthorName
Parameter prm prmProcessingDate
Property prp prpName
Recordset rs rstClients
6.2.6 Descriptive Variable and Procedure Names
The body of a variable name should use mixed case and should be as long as necessary to
describe its purpose. The names should be a Noun.
For frequently used or long terms, standard abbreviations are recommended to help keep name
lengths reasonable. In general, variable names greater than 32 characters can be difficult to read on
VGA displays.
When using abbreviations, make sure they are consistent and unambiguous throughout the entire
application. Randomly switching between Cnt and Count within a project will lead to unnecessary
confusion.

6.2.7 User-Defined Types

In a large project with many user-defined types, it is often useful to give each such type a three-
character prefix of its own. To achieve this, these prefixes should begin with "u," since they will
be easy to recognise quickly when working with a user-defined type.
Example: “uClient” could be used as the prefix for variables of a user-defined Client type.
6.3 Qualifiers
Often related variables are used to manage and manipulate a common object, in these cases it can be
very helpful to use standard qualifiers to label the derivative variables. Although putting the qualifier
after the body of the name might seem a little awkward (e.g. msNameFirst, msFirstName and so on).
The following table defines the common Qualifiers and their standard meanings

Qualifier Description Qualifier Example

First element of a set First sNameFirst
Last element of a set Last SnameLast
Next element in a set Next nSortValueNext
Previous element in a set Prev nSortValuePrevious
Current element in a set Curr nSortValueCurr
Minimum element in a set Min nSalaryMin
Maximum element in a set Max nSalaryMax
A scratch variable with localized Tmp nRegisterTmp
scope
Source Src nRegisterSrc
Destination Dst nRegisterDst
Old value of element in a set Old nClientCodeOld
New value of element in a set New nClientCodeNew

Do not define multiple variables (of same type) on the same line of variable definition, instead one must use
different lines for each variable declaration.
If two variables declared on same line as follows
Dim intCount, intNumber as integer
Then only intNumber becomes integer type and intCount becomes Default type (Variant). This may cause
problems like type mismatch while passing by reference, etc. Instead use the following method:
Dim intCount as integer;
Dim intNumber as integer.

Suffix is the optional VB type character, e.g. $, %, # etc.

6.4 Function and Subroutine

Functions and Subroutines names should adopt the follow convention:
<Prefix><Body><Qualifier> where,

<Prefix>
Routine Type Prefix Example
Function fn fnGetWorkOrderNumber
Sub Routine sb sbSetWorkOrderNumber

<Body>
The body of function / subroutine names should use mixed case and should be as long as needed to describe
their purpose, e.g. fnGetWorkOrderNumber, sbSetWorkOrderNumber.
In addition, function names should begin with a verb, such as fnInitNameArray or fnCloseDialog.

<Qualifier>
Apply all the rules of the Qualifier of variable naming conventions.
In addition, one should pass arguments to subs and functions using ByVal, unless it is explicitly needed to
change the value of the passed argument.
6.5 Menus
Because menu handlers can be so numerous, menu names require a little more attention.
Menu prefixes therefore continue beyond the initial menu label by adding main menu name
prefix for each level of nesting, with the final menu item caption being spelled out at the end
of the name string.
5. Menu names have the following structure: mnu<Main menu><Menu item><Sub Menu
item>...

Menu Action Menu Name

File mnuFile
File.Open mnuFileOpen
File.Send.Fax mnuFileSendFax
File.Send.Email mnuFileSendEmail