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
Eg1
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.
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.
Source : Unknown
