PBDR.COM

About   -   Contact   -   Purchase   -   Search   -   What's New

 
 

Coding Standards for Visual Basic (2/2)

Procedure & Coding Formats

Procedure Format Standards

Coding of Procedures/Sub-routines should be done in such a way as to ensure the code is as easy to read as possible. This involves the indentation and spacing of code in order to distinguish between specific processes and functions within the code, as shown in the example below.

Private Sub cmdButton_Click()

    Dim strString as string
    Dim blnBoolean as boolean

    On Error Goto ErrorHandler     

    ''''''''''''''''''''''
    ' This is an example '
    ''''''''''''''''''''''

    strString = "Hello"
    
    If blnBoolean then
        If Function(strString) then
            Exit sub 
        End if
    End if

    Exit Sub

ErrorHandler:

     Msgbox err.number & ":" & err.description, vbcritical, _
       "cmdButton_Click"

End Sub
The same code without spacing or indentation proves much more difficult to read (see below).
Private Sub cmdButton_Click()
DIM strString as string
DIM blnBoolean as boolean
On Error Goto ErrorHandler
''''''''''''''''''''''
' This is an example '
''''''''''''''''''''''
strString = "Hello"
If blnBoolean then
If Function(strString) then
Exit sub
End if
End if
Exit Sub
ErrorHandler:
Msgbox err.number & ":" & err.description, _
vbcritical,"Button  Click
End Sub

Procedure specific variable declarations should be grouped together at the top of the procedure. Where appropriate attempt to group variables by common threads (i.e. Variables associated with particular processes or with common functions.) and then group by datatype. This rule should also be applied to variables declared as Option Explicit

Try to keep procedures to a manageable size. If this requires the movement of code to sub-routines or functions then do this. Although the code may be split it will still be much easier to read and understand in smaller chunks.


Langauge Statement Standards

The following are guidelines to a few language statements.

IF Statement

The IF statement should be indented at each if level. The corresponding ELSE should align with the IF, as shown 

Eg 1
If blnBoolean then
    If blnFunction(strString) then
	Exit sub 
    End if
End if

Eg 2
If blnBoolean then
    If blnFunction(strString) then
	Exit sub
    Else
	IntCounter = intCounter + 1 
    End if
Else
    Msgbox "Boolean is false" 
End if

Avoid creating IF statements over six levels deep as the comprehension of IF statements becomes increasing difficult the deeper they become.

Select Case Statement

Select Case intMenuItem
    Case 1
        frmFinance.Show 
    Case 2
        frmStock.show
    Case 3
        If blnSecurityPass Then
            frmPass.show
        Else
            Msgbox "You do not have access authority."
        End if
End select


For...Next Statement

For intIndex = 1 to intLastRecord
    If datStartDate(intIndex) > now() then
        blnErrorFlag(intIndex) = True
    Else
        blnErrorFlag(intindex) = False 
    End if
Next intIndex


Note: the NEXT statement contains a reference to the counter (intIndex),even though it is not required for functionality. This should be done for all FOR...NEXT loops to add clarity, especially where loops are embedded within loops.

While...Wend Statement
Dim intCounter

intCounter = 0

While intCounter < 20
    intCounter = intCounter + 1 
Wend

GOTO Statement

The GOTO statement should be avoided at all times as it can create confusing jumps in code. The notable exception to this rule is the 'On Error GoTo' statement.

Form Design Standards

Forms and Controls

Windows Standards should be used for all forms and controls unless the customer has specified otherwise. 
Object BackGround ForeGround
Form Grey Black
Control (Enabled) White Black
Control (Locked/Disabled) Grey Black


Where possible, Controls should be set to 'Locked = True' rather than 'Enabled = False' to allow greater development control over colour as well as clarity of control content for the user.

An application wide font of MS Sans Serif size 8 should be used to provide system conformity. This, of course, is subject to sensible variations to accommodate user and formatting requirements.

Confirmation and Rejection command buttons should use 'OK' and 'Exit' as their text, in order to match the Windows standard. Any deviation from this should only be at the customers specific request.

Enabled or non-locked controls such as TextBoxes and ListBoxes should have a 'Fixed Single' Border Style property and '3D' Appearance. Labels should have an Appearance property of 'Flat'.

Menus

All major forms should possess a menu bar unless otherwise specified by the user. The menu bar items should be presented using the Windows standard menu style and naming conventions (i.e. Hierarchical menus with Hot keys using item names the same as, or similar to Windows menu item names - see example below). Where there are Command Buttons available on the form, then these activities should be included within the menu where relevant.

Eg.

File         View              Help
  Add         Forecasts     Help F1
  Modify     Invoices        Contents
  Delete
  Exit

     
Error Handling

All sub-routines, where even a small degree of processing is involved, should contain error handling. 

System errors should not be displayed to the user, the code should control the system errors, displaying a user friendly and informative message relating to the processes being undertaken at the time of the error. Eg.

         "Unable to retrieve the selected record."

The system error number, description and the location where it occured (form/module and procedure) should then be written to a log file. This provides valuable debugging information and can then be referenced by the System Administrator. It is preferable for the Error logging routine to be a common function, which could be held in a DLL.

Where there is any database connection and utilisation the error handling must be comprehensive. Again, it is preferable for all database error handling to handled by a common function which can filter the database errors.

In the absence of a common Error Handling Routine for the Project then errors should be handled as shown in 'Procedure and Coding Formats'. Ensure the error message box contains some reference to where the error occured (e.g. the message box title bar) for easier debugging. Where there is any database connection and utilisation ensure that the error handling is comprehensive. The user should not receive any system messages, particularly with regard to ODBC errors. 

Return to VB Coding Standards (1/2)

 

Top of Page

Legal Notice

Ken Howe 2011