[kalyansantosh]

VBscript Coding Standards

The following puts forward the naming conventions and coding standards to be used when producing QuickTest Pro and VBscript scripts.

1 Naming Conventions
1.1 Routine Naming Conventions
Pascal casing will be used for naming functions, subroutines and classes. (Pascal casing specifies that the first character of every word in the name is capitalized.)

The following are examples of Pascal cased routine and class names:

Public Function ExtractDate (ByVal sEncodedTimeDate)
Sub ReverseString (ByVal sOriginalString, ByRef sReversedString)
Class ExcelSpreadsheetObject

1.2 Variable Naming Conventions
All VBScript variables are of type “variant,” but it is useful to use variable prefix codes to indicate the primary type of data that they are designed to hold. For this reason, Camel casing will be used for naming variables and objects.

The following are examples of Camel cased variable and object names:

str_SearchString
bin_ProcessingComplete
int_CurrentMonth

The following paragraphs provide details on the variable prefixes to be used when naming variables and objects.
1.2.1 General VBScript Variable Prefixes


Variable Type Example
Constant c_TestPath
Character (Single) chr_Delimiter
Integer Int_Count
Real flt_StockPrice
String str_ExpectedText
Array arrNewArray
Boolean bln_Exists
Object obj_Object
Loop index (single letter) – i to n

1.2.2 Common ADO and FSO Object Prefixes

Common objects instantiated

Object Type Example
ADO connection con_NewConnection
ADO command cmd_NewCommand
Record Set rs_Users
File system object fso_Filesystem
Windows script host wsh

1.2.3 QuickTest Pro Specific Variable Prefixes

Variable Type Examples
Data Table Column dt_FirstName
A test object defined using descriptive programming (i.e. not in the Object Repository) should be formatted as follows:

to<ObjectClass><Description> to_PageCSRHomePage
to_WebLinkNeedHelp

1.3 External File Naming Conventions

Naming of external files should follow the Pascal case convention and should be as descriptive as possible.

The following are examples of proper external file names:

StringUtilities.vbs
CreditCardScenarios.xls
CarsToCancelUK.txt

2 Coding Standards
2.1 Keywords
All keywords should be capitalized.
2.2 Prologues
2.2.1 Library File Prologues

A file preface should appear at the beginning of each library file. The purpose of this foreword is to provide an overview of the functionality that is contained within the file itself. It should NOT contain lists of the specific routines and variables contained within the file.

The following is an example of a file prologue:

'*************************************************************************************
' Library File: StringUtilities
'
' Description: This file contains basic string handling/manipulation utility routines.
'
'*************************************************************************************
2.2.2 Class Prologues
A class introduction should appear at the beginning of each class. The purpose of this prologue is to provide a description of the class itself and to list the properties and methods of the class. It is not used for providing details of the processing that support those methods and properties.

The following is an example of a class prologue:

'************************************************************************
' Class: Stack
'
' Description: Standard data structure which allows elements to be stored
' and retrieved in a "First-In, Last-Out" order. When an
' element is added to the top of the stack, no other
' elements beneath it can be accessed until that element has
' been removed.
'
' Properties:
'
' NumEntries (read only) - Integer value specifying the number of
' valid entries currently on the stack
'
' Methods:
'
' Push - Adds provided element to the top of the stack
' Pop - Removes and returns top element from stack
' GetTopElement - Returns top element from the stack without
' removing it from the stack
' GetContents - Returns an array containing the contents of the
' stack without modifying the stack
'
'************************************************************************
2.3 Comments

Comments are used to help anyone who is attempting to understand and maintain the actual code. For consistency, all comments should adhere to the following guidelines:
• Comments should be included in scripts to provide an explanation of what the code is doing and to make it easier for the reader to understand and maintain it. For this reason, it is not necessary to try to comment each individual line or to describe obvious code, but it is necessary to comment major blocks of code.
• Comments lines should begin with the ‘ character indented at the same level as the code they are documenting.
• Code comments should be written in clear, concise English with correct spelling and grammar.
• Comments should not be used to teach the reader how to program. Assume the reader knows as much about the programming language as you do.
• The purpose of comments is to increase your code readability. Often using good variable and method names make the code easier to read than if too many comments are present.
• When "commenting out" code include a description why you did so. If the code isn't necessary, it should be deleted.
• Do not use "clutter" comments, such as an entire line of asterisks. Instead, use a single blank line white space line to separate comments from code.

2.4 Function and Subroutine Coding Guidelines

Functions and subroutines are used to break the code into reusable, maintainable units. For consistency, functions and subroutines should adhere to the following guidelines:
• Although functions and subroutines are considered to be public by default, all should be explicitly identified as being either public or private to eliminate the possibility of confusion.
• By default, parameters are passed by reference into functions and subroutines. However, all should by explicitly identified as being passed either ByRef or ByVal to eliminate the possibility of confusion.
• Exit statements should not be used except for in extreme and unusual circumstances.
• A single assignment at the end of the function immediately before returning control to the caller.
• Dynamically created objects and variables upon use in functions and subroutines, all should be specifically declared by a private or dim statement at the start of the routine. Each variable and object should be declared in its own separate statement.

The following provides an example of a function that adheres to these guidelines:

Public Function AddValues (ByVal iAddend1, ByVal iAddend2, ByRef iSum)
Dim int_TempSum
Dim bln_ReturnValue

‘ Initialize function return status value and prepare to handle errors.

bReturnValue = False
On Error Resume Next

‘ Attempt to add the two values together.

Int_TempSum = int_Addend1 + int_Addend2

‘ Update the return values if no error occurred.

If Err.Number = 0 Then
int_Sum = iint_TempSum
bln_ReturnValue = True
End If

‘ Return status to the caller.

AddValues = bln_ReturnValue
End Function

2.5 Code Formatting Guidelines

In general, all statements inside classes, functions, subroutines and control statements should be indented one tab stop, No spaces are used to maintain indent alignment.

2.5.1 Class Formatting Guidelines
All variable, object, property, method, and routine declaractions within a class should be indented one tab stop (or 4 character spaces). Whenever possible, all variable declarations should be placed together at the start of the class, followed by the constructor and destructor routines, then by properties, then by methods, and finally by local functions and subroutines.

The following is the proper format for a class:

Class <class name>
Statements
End Class
2.5.2 Function Formatting Guidelines
All variable, object, and statements within a function should be indented one tab stop. Whenever possible, all variable declarations should be placed together at the start of the function prior to any executable statements.

The following is the proper format for a function:

Public | Private Function (parameters)
Statements
End Function
2.5.3 Subroutine Formatting Guidelines
All variable, object, and statements within a subroutine should be indented one tab stop. Whenever possible, all variable declarations should be placed together at the start of the subroutine prior to any executable statements.

The following is the proper format for a subroutine:

Public | Private Sub (parameters)
Statements
End Sub
2.5.4 Do Loop Statement Formatting Guidelines
There are four basic statements for a Do Loop statement: two that check for the expected condition prior to executing the loop, and two that check after execution. For each, any statements executed within the loop should be indented one tab stop (or 4 character spaces).

Exit statements should not be used except for in extreme and unusual circumstances.

The following are the proper formats for the Do Loop statements:

Do While | Until <condition>
Statements
Loop

or

Do
Statements
Loop While | Until <condition>

2.5.5 For… Next Statement Formatting Guidelines
All statements executed within a For…Next loop should be indented one tab stop.

Exit statements should not be used except for in extreme and unusual circumstances.

The following is the proper format for a For… Next statement:

For counter = value To end value [Step step count]
Statements
Next
2.5.6 For Each… Next Statement Formatting Guidelines
All statements executed within a For Each…Next loop should be indented one tab.

Exit statements should not be used except for in extreme and unusual circumstances.

The following is the proper format for a For Each… Next statement:

For element In group
Statements
Next
2.5.7 If… Then… Else Statement Formatting Guidelines
All statements executed as part of an If… Then… Else statement should be indented one tab stop

The following is the proper format for an If… Then… Else statement:

If condition Then
Statements
ElseIf condition Then
Statements
Else
Statements
End If
2.5.8 Select Case Statement Formatting Guidelines
All statements executed as part of a Select Case statement should be indented one tab stop
The following is the proper format for a Select Case statement:

Select Case test-expression
Case expression-list
Statements
Case Else
Statements
End Select
2.5.9 While… Wend Statement Formatting Guidelines
All statements executed as part of a While…Wend statement should be indented one tab stop
The following is the proper format for a While… Wend statement:

While condition
Statements
Wend
2.5.10 With Formatting Guidelines
A With statement allows you to perform a series of statements on an object without having to constantly requalify the object. All statements being associated with the With statement should be indented one tab stop

With object
Statements
End With