Visible Progress Home We make progress visible.
Search Site:
Resources > VB6 Coding Tips  
VB Quality Zone
VB6 Coding Tips
Self-documenting Code
Coding Standards
Naming Conventions
Error Handling
Binary Compatibility
Performance Tuning
Source Metrics
Process Tips
Testing Tips

Our Customers...
What Customers Say...

VS Law 2005 - VB.NET 2005 coding standards enforcement.
Try our products for free today.
VS Law .NET - VB.NET 2002/2003 coding standards enforcement.
Try our products for free today. VB Law - VB6 coding standards enforcement.
 
  VB Law - Quality assurance for Visual Basic source code.  
 

Visual Basic Coding Standards

Paper coding standards are not enough!
Paper coding standards soon become worthless if they cannot easily be enforced and the time and effort spent creating them is lost. VB Law Workstation automates reviews for coding standards compliance from directly within the Visual Basic 6 Integrated Development Environment adding considerable value to the time already invested in coding standards creation. Visit our downloads page and trial VB Law for free. Begin effective VB coding standards enforcement today.

The VB Coding Standards document below was generated by VB Law from the VB Law sample rulebase of professional VB Coding Standards included free with VB Law. Using VB Law Administrator (the flexible rule editor) you can easily create new rules, amend existing rules or disable rules that aren't appropriate to your organisation. ALL of the rules below can be enforced by VB Law.


Sample VB Coding Standards Rulebase

6.2.0208

Sample.law

for

Visible Progress Technologies




Published: 02 November 2004




This rulebase uses sample rules written by professional VB programmers to demonstrate how an organisation's Visual Basic coding standards can be enforced using VB Law from Visible Progress Technologies.
Table Of Contents

Project Properties
Table Of Contents > Project Properties

Groups together all rules relating to project property settings.
 
Project Title Must Be Defined [0013] Medium (500)
The project title must always be set to something meaningful as it is used in the Windows task list and for message box captions when no default is supplied in the call to the message box function.  
 
Compiled Component Filenames Must Be 8.3 Format [0185] Critical (900)
All compiled components must follow the 8.3 naming format for filenames.  
 
Project File Name Must Match Component File Name [0010] High (750)
The project file name (excluding path and extension) must match the compiled component file name (excluding path and extension).  
 
Auto Increment Version Number Must Not Be Set [0019] Low (250)
In order to control the use of version numbers for correct configuration management, the auto increment feature should be switched off. Version numbers must not be incremented accidentally.  
 
Upgrade ActiveX Controls Must Be Unchecked [0012] High (750)
The project option of upgrading ActiveX Controls must not be checked as installation sets must be similarly updated, therefore all upgrading of controls must be by deliberate intent and not by accident.  
 
Remove Information About Unused ActiveX Controls Must Be Checked [0207] Medium (500)
The project option of removing information about unused ActiveX controls must be checked.  
 
Version Info - Company Name Must Be Set [0015] Low (250)
The company name entry in the version information must be set.  
 
Version Info - File Description Must Be Set [0016] Low (250)
The file description entry in the version information must be set.  
 
Version Info - Legal Copyright Must Be Set [0017] Low (250)
The legal copyright entry in the version information must be set.  
 
Version Info - Product Name Must Be Set [0018] Low (250)
The product name entry in the version information must be set.  
 
Project Must Be Tested Within The IDE And Compiled [0183] Critical (900)
It is essential that projects are unit tested both within the Visual Basic IDE and externally as compiled components.  
 
All Components Must Offer Context-Sensitive Help [0124] High (750)
A help file must be associated with all components. For application modules, help files should describe key application features and operational instructions. For ActiveX components, help files should describe component design goals, classes, methods, properties and enums etc. to aid re-use by other developers.  
 
Compilation Options
Table Of Contents > Compilation Options

Groups rules relating to component compilation.
 
Advanced Optimizations [0022] Medium (500)
Advanced compiler optimizations should only be set under very special and controlled circumstances.  
 
Create Symbolic Debug Info [0024] High (750)
This compiler option should only ever be set when producing a debug build for use with a debugging tool that can use it and must not be used for release builds.  
 
Favour Pentium Pro [0023] High (750)
This compiler option should only ever be set when the target machine has a processor that supports the instruction sets first introduced with the Intel Pentium Pro processor.  
 
Standard EXE Components
Table Of Contents > Standard EXE Components

Groups rules related to the coding techniques applicable to the creation of standard EXE components.
 
Application Startup Object Must Be "Sub Main" [0011] Medium (500)
The application start-up object must always be 'Sub Main' for standard EXE components.  
 
Project Icon Must Be Set [0014] Medium (500)
The project icon should be set as it becomes the application icon when the project is compiled.  
 
ActiveX Components
Table Of Contents > ActiveX Components

Groups rules related to the coding techniques applicable to the creation of ActiveX components.
 
Project Description Must Be Specified For ActiveX Components [0116] High (750)
The project description on the 'General' tab of the Visual Basic Project Properties dialog must contain a meaningful description for this ActiveX component to identify it for selection on the Visual Basic Project Components / References dialog.  
 
Do Not Use "End" In Out-Of-Process Server Components [0112] High (750)
Do not use the "End" statement to forcefully unload an ActiveX EXE server as this can leave client applications unaware that the server has exited. Servers should be loaded and unloaded using the normal COM reference counting approach which is implemented automatically by Visual Basic.  
 
Binary Compatibility
Table Of Contents > Binary Compatibility

All ActiveX components must maintain binary compatibility and follow component versioning rules.
 
ActiveX Components Must Be Binary Compatible [0119] Critical (900)
Prior to the release of any ActiveX component, the project must be compiled to create a binary image of the component and then the version compatibility option on the 'Component' tab of the Visual Basic project properties dialog set to binary compatibility.  
 
ActiveX Components Must Reference A Compatible Image [0125] Critical (900)
All ActiveX components must reference a binary image of the component located in the 'Compat' folder directly beneath the project folder. Note: To avoid complex version trees, this image must be updated whenever the component's class interfaces are extended.  
 
Source Files
Table Of Contents > Source Files

Groups together conventions related to source files (including file naming, related documents and resource files).
 
"Option Explicit" Must Appear In All Source Files [0003] Critical (999)
The 'Option Explicit' statement must be used at the head of all source files to ensure that variables can only be used if declared prior to use. Use of the 'Option Explicit' statement helps to avoid bugs caused by mis-spelling of variable names.  
 
Source Files Must Reside In Project File Folder [0025] Critical (900)
To ensure that all source files pertaining to a Visual Basic project are correctly archived, all project source files must reside in the same folder as the Visual Basic project file (.VBP).  
 
Resource File Name Must Match Project Name [0097] Critical (900)
For projects utilising a Windows resource file, the filename of the resource file (excluding file extension) must match the project filename (excluding file extension).  
 
Class Names Must Be Correctly Prefixed [0216] High (750)
The Name attribute of a class file must be prefixed 'cls'.  
 
Class Files Must Use The Correct Extension [0186] High (750)
Class filenames must use the Visual Basic default extension of '.cls'.  
 
Designer File Names Must Be Correctly Prefixed [0217] High (750)
The Name attribute of a designer file must be prefixed 'dsr'.  
 
Designer Files Must Use The Correct Extension [0222] High (750)
The extension of designer files must match the Visual Basic default extension of '.dsr'.  
 
Form Files Must Use The Correct Extension [0223] High (750)
Form filenames must use the Visual Basic default extension of '.frm'.  
 
MDI Form Names Must Be Correctly Prefixed [0214] High (750)
The Name attribute of an MDI form file must be prefixed 'mdi'.  
 
MDI Child Form Names Must Be Correctly Prefixed [0221] High (750)
The Name attribute of an MDI child form file must be prefixed 'frm'.  
 
Non-MDI Form Names Must Be Correctly Prefixed [0213] High (750)
The Name attribute of a non-MDI form file must be prefixed 'frm'.  
 
Module Names Must Be Correctly Prefixed [0215] High (750)
The Name attribute of a module file must be prefixed 'mod'.  
 
Module Files Must Use The Correct Extension [0224] High (750)
The extension of module filenames must use the Visual Basic default extension of '.bas'.  
 
Property Page Names Must Be Correctly Prefixed [0219] High (750)
The Name attribute of a property page must be prefixed 'ppg'.  
 
Property Page Files Must Use The Correct Extension [0225] High (750)
The extension of property page filenames must use the Visual Basic default extension of '.pag'.  
 
User Control Names Must Be Correctly Prefixed [0220] High (750)
The Name attribute of a user control must be prefixed 'uctl'.  
 
User Control Files Must Use The Correct Extension [0226] High (750)
The extension of user control filenames must use the Visual Basic default extension of '.ctl'.  
 
User Document Names Must Be Correctly Prefixed [0218] High (750)
The Name attribute of a user document must be prefixed 'udoc'.  
 
User Document Files Must Use The Correct Extension [0227] High (750)
The extension of user document files must match the Visual Basic default extension of '.dob'.  
 
Constant Declarations
Table Of Contents > Constant Declarations

Groups rules relating to the declaration of constants.
 
Constant Scope Must Always Be Specified [0095] High (750)
The scope for a module-level 'Const' declaration must always be explicitly declared Public or Private as appropriate.  
 
Constant Data Type Must Be Explicitly Specified Using "As" Keyword [0067] Medium (500)
The "As" keyword must be used within a constant declaration to explicitly state the data type of the declared constant.  
 
Multiple Item "Const" Declarations Must Not Be Used [0064] Medium (500)
To avoid confusion and aid readability, individual constants must be declared using separate "Const" statements.  
 
Public Constant Names Must Be Correctly Formed [0233] High (750)
All public constant names must take the form g_<data type prefix><body>. The body of public constant names must always be upper case and underscore characters may be included to aid readability. Public constant names must not use Visual Basic data type suffix characters but must instead use the "As" keyword to specifically state the constant data type.  
 
Private Module-level Constant Names Must Be Correctly Formed [0235] High (750)
All private module-level constant names must take the form m_<data type prefix><body>. The body of private module-level constant names must always be upper case and underscore characters may be included to aid readability. Private module-level constant names must not use Visual Basic data type suffix characters but must instead use the "As" keyword to specifically state the constant data type.  
 
Local Constant Names Must Be Correctly Formed [0234] High (750)
All local constant names must take the form <data type prefix><body>. The body of local constant names must always be upper case and underscore characters may be included to aid readability. Local constant names must not use Visual Basic data type suffix characters but must instead use the "As" keyword to specifically state the constant data type.  
 
Variable Declarations
Table Of Contents > Variable Declarations

Groups all rules dealing with the declaration and usage of variables.
 
"Dim" Must Not Be Used For Module-level Variable Declaration [0056] Low (250)
The "Dim" keyword must not be used for module-level variable declaration. Module-level variables must always be defined using the "Private" keyword.  
 
Multiple Item Variable Declarations Must Not Be Used [0063] Medium (500)
To aid readability, individual variables must be declared on separate source lines.  
 
Variables Must Not Be Declared "As New" [0102] High (750)
Variables must not be declared using the "As New" syntax which supports on demand creation of objects. To give a clear indication of the intended object lifetime, all object variables must be instantiated using the "= New", or "= CreateObject()", syntax. A small amount of additional processing overhead is also associated with variables declared using the "As New" syntax which may degrade operational performance.  
 
"Public" Variables Must Not Be Used In Classes [0074] Critical (900)
Public variables must not be used in classes. Instead, private member variables should be used which are accessed via property procedures.  
 
"ReDim" Must Not Be Used For Variable Declaration [0033] Medium (500)
Checks to see if any code lines contain "ReDim...As" statements. The "ReDim" statement must not be used to initially dimension an array, merely to redimension it.  
 
"To" Keyword Must Be Used For Array Variable Declaration [0057] Medium (500)
When declaring an array variable, both the lower and upper bounds must be specified using the "To" keyword.  
 
Variable Data Type Must Be Explicitly Specified Using "As" Keyword [0058] Medium (500)
The "As" keyword must be used within a variable declaration to explicitly state the data type of the declared variable.  
 
Local Variable Names Must Be Correctly Formed [0231] High (750)
All local variable names must take the form '<array prefix><data type prefix><body>'. The body of a variable name must employ mixed case, exclude underscore characters and be at least two characters long. Variable names must not use Visual Basic data type suffix characters but must instead use the "As" keyword to specifically state the variable data type.  
 
Local Static Variable Names Must Be Correctly Formed [0232] High (750)
All local static variable names must take the form 'st_<array prefix><data type prefix><body>'. The body of a local static variable name must employ mixed case, exclude underscore characters and be at least two characters long. Variable names must not use Visual Basic data type suffix characters but must instead use the "As" keyword to specifically state the variable data type.  
 
Private Module-level Variable Names Must Be Correctly Formed [0230] High (750)
All module level Private variable names must take the form 'm_<array prefix><data type prefix><body>'. The body of a variable name must employ mixed case, exclude underscore characters and be at least two characters long. Private variable names must not use Visual Basic data type suffix characters but must instead use the "As" keyword to specifically state the variable data type.  
 
Public Variable Names Must Be Correctly Formed [0229] High (750)
All public variable names must take the form 'g_<array prefix><data type prefix><body>'. The body of a variable name must employ mixed case, exclude underscore characters and be at least two characters long. Public variable names must not use Visual Basic data type suffix characters but must instead use the "As" keyword to specifically state the variable data type.  
 
Public "WithEvents" Variable Names Must Be Correctly Formed [0152] High (750)
All Public WithEvents variable names must take the form 'g_evt<body>'. The body of a variable name must employ mixed case, excluding underscore characters and be at least two characters long.  
 
Private "WithEvents" Variable Names Must Be Correctly Formed [0228] High (750)
All Private WithEvents variable names must take the form 'm_evt<body>'. The body of a variable name must employ mixed case, excluding underscore characters and be at least two characters long.  
 
Local Object Variables Must Be Explicitly Destroyed [0268] High (750)
Object variables created in a procedure should be explicitly set to Nothing at the end of the procedure.  
 
Member Object Variables Must Be Explicitly Destroyed [0269] High (750)
Member object variables should be explicitly set to Nothing after usage.  
 
Enum Declarations
Table Of Contents > Enum Declarations

Groups rules related to the declaration of enums (including their elements).
 
Enum Scope Must Always Be Specified [0081] High (750)
The scope for an 'Enum' declaration must always be explicitly declared Public or Private as appropriate.  
 
Enum Elements Must Always Specify A Value [0082] Medium (500)
To aid clarity and debugging, enum elements must always specify a value.  
 
Enum Element Names Must All Share The Same Prefix [0086] Medium (500)
To aid clarity of usage, the names of enum elements for an individual enum definition must all begin with the same prefix. The prefix chosen should be at least 2 characters.  
 
Enum Names Must Be Correctly Formed [0149] High (750)
Enums intended for use as parameter / property values must have names which end with the suffix 'Constants' whilst enums intended for use as return codes from procedure calls must end with the suffix '_RESULT'.  
 
Hidden Enum Element Values Must Not Be Declared [0084] Medium (500)
To ensure components are easy to use and understand, hidden enum elements must not be defined.  
 
Enum Element Values Must Be Numeric [0206] Medium (500)
Despite the Visual Basic compiler allowing string literals to be defined for enum element values, enum element values must always be numeric. For example: eMyValue = "55" is not allowed and should instead be defined as eMyValue = 55.  
 
User-defined Types
Table Of Contents > User-defined Types

Groups rules relating to the declaration and use of user-defined types.
 
Type Element Names Must Be Correctly Formed [0192] High (750)
All elements of a user-defined type must take the form '<data type prefix><body>'. The body of an element name must employ mixed case, exclude underscore characters and be at least two characters long. Element names must not use Visual Basic data type suffix characters but must instead use the "As" keyword to specifically state the element data type.  
 
Type Names Must Be Correctly Formed [0191] High (750)
To differentiate a user-defined type definition from an instance of a user-defined type all user-defined type names must end with the suffix "Type".  
 
Procedure Declarations
Table Of Contents > Procedure Declarations

Conventions relating to the declaration of procedures, including procedure arguments.
 
"Static" Procedure Declarations Must Not Be Used [0037] Medium (500)
If a procedure is declared with static scope then all local variables whether or not they are explicitly declared static, are static in scope. This can cause problems if the code relies on variables being initialised to default values. Procedures which require static variables should explicitly declare variables as static (or use private module-level variables) and must not declare the procedure itself 'Static'.  
 
Argument Data Type Must Be Explicitly Specified Using "As" Keyword [0154] High (750)
The "As" keyword must be used within an argument declaration to explicitly state the data type of the declared argument.  
 
Argument Names Must Be Correctly Formed [0151] High (750)
Arguments are prefixed according to their calling convention (ByVal/ByRef) and data type.  
 
Arguments Must Be Explicitly Declared "ByRef" Or "ByVal" [0076] High (750)
All procedure/declare/event arguments must be explicitly declared to state whether an argument is passed by reference or by value by using the appropriate 'ByRef' or 'ByVal' keyword.  
 
Avoid "Default" Procedure Attributes [0176] Medium (500)
Avoid assigning default procedure attributes which can become the source of unexpected bugs.  
 
Avoid Use Of "ParamArray" Procedure Arguments [0187] Info (0)
Procedures requiring the use of ParamArray arguments are rare and should only be used for special circumstances.  
 
Optional Arguments Must Define A Default Value [0166] High (750)
All optional procedure arguments must define a default value.  
 
Procedure Return Data Type Must Always Be Specified [0039] Medium (500)
Always specify the return data type for functions and properties. If a return type for a function or property is not explicitly declared, then it will default to Variant. The variant data type should only be used when more than one type needs to be supported. Even then, it avoids any confusion if the author explicitly states that the function or property return data type is 'Variant'.  
 
Procedure Scope Declaration Must Always Be Specified [0038] High (750)
Unless the procedure scope is explicitly declared Public, Private or Friend, it is not obvious what scope the author intended and thus whether a procedure should be used outside the module or not. For this reason, the scope of a procedure must always be stated explicitly using the appropriate keyword.  
 
Procedures Must Have Only A Single Exit Point [0156] High (750)
Procedures must contain only a single exit point. Having a single exit point simplifies debugging and can help to ensure that cleanup code is executed prior to exiting the procedure.  
 
Procedures Must Not Return Arrays [0178] High (750)
Procedure return data types must not return arrays. Due to a known bug in Visual Basic 6.0, when you use a function that returns an array as a parameter to the UBound or LBound functions, the memory allocated for the array is not released thereby causing a memory leak. (See knowledge base article Q197190.)  
 
VB Data Type Characters Must Not Be Used For Procedure Declaration [0090] Medium (500)
Procedure names must not use the VB data type suffix characters but must instead use the "As" keyword to specifically state the return data type.  
 
Procedures Must Explicitly Assign Return Values [0260] High (750)
Functions and Property Get procedures must ensure that a return value is always explicitly set using an assignment statement e.g. FunctionName = Value.  
 
Code Layout
Table Of Contents > Code Layout

Groups together rules relating to code layout and formatting. To reduce maintenance and future development costs, it is essential that source code layout and formatting is consistent, making code easy to read and understand.
 
Use A Single Statement Per Line [0028] High (750)
All statements should be clearly arranged on a separate line. Concatenation of multiple statements per line using the ":" separator must be avoided.  
 
Use Line Continuation Characters To Break Long Lines [0110] Low (250)
To aid readability, an individual source line must not exceed 85 characters in width without the use of the line continuation character ("_").  
 
Statements Must Use Appropriate Indentation [0026] Medium (500)
Checks to ensure that all statements within procedures are properly indented.  
 
Single Line "If...Then" Statement Must Not Be Used [0027] High (750)
In the interest of making source code more readable, single line If...Then statements are to be avoided i.e. the 'End If' keyword must be used for all 'If' statements.  
 
"For...Next" Counter Variable Must Not Be Omitted [0030] High (750)
To aid source code readability, all "For...Next" loops must include the name of the loop counter variable after the "Next" keyword.  
 
Variables Must Be Declared At The Head Of A Procedure [0201] High (750)
To aid code readability, all local variables must be declared at the head of a procedure.  
 
Constant Declarations Must Precede Variable Declarations [0071] High (750)
All constant declarations must appear before variable declarations within the declarations section of a source file.  
 
"Public" Constant Declarations Must Precede "Private" Constant Declarations [0072] High (750)
All Public constant declarations must appear before private constant declarations within the declarations section of a source file.  
 
Sub/Function Definitions Must Not Exceed 200 Lines [0073] High (750)
To aid readability of source code, individual Sub and Function definitions must not exceed 200 source lines.  
 
Property Procedures Must Not Exceed 5 Lines [0083] High (750)
To aid readability of source code, individual Property Get/Let/Set procedure definitions must not exceed 5 code lines. Property procedures must be used only for access to private member variables.  
 
Declaration Only Source Files Must Be Avoided [0091] Medium (500)
Source files containing declarations only must be avoided. Constants, enums, type definitions, declare statements and variables etc. are best grouped with the procedures to which they relate, rather than as part of special "declaration only" source files.  
 
Empty Procedures Should Be Removed [0120] High (750)
Empty procedure declarations must not be left in source files. First, remove references to the obsolete procedure and then remove the procedure itself. Only classes used to define COM interfaces may contain empty procedures. (Interface classes are denoted by names beginning with "I".)  
 
Line Label Names Must Be Correctly Formed [0164] High (750)
Line labels must be used only to label a procedure's error handler routines and exit point.  
 
Individual Property Get/Let/Set Procedures Must Be Grouped Together [0261] Medium (500)
The property procedures for an individual property with more than one access method (Get, Let or Set) must not be separated by other procedures but should always be grouped together.  
 
Code Complexity
Table Of Contents > Code Complexity

Groups together rules relating to code complexity. To reduce maintenance and future development costs, it is essential that source code complexity is kept to a minimum thereby ensuring code is easy to understand, modify and test.
 
"If...Then" Statements Must Not Be Nested More Than 3 Levels [0131] Critical (900)
To ensure that procedures are easy to understand, test and maintain, 'If...Then' statements must not be nested beyond three levels deep.  
 
Argument List Must Not Exceed 7 Arguments [0075] High (750)
To simplify unit testing, procedures must not exceed the maximum of seven arguments.  
 
Avoid Declaring Excessive Numbers Of Variables In A Single Procedure [0204] High (750)
To keep procedures simple to read and understand, try to avoid declaring excessive numbers of local variables within a procedure.  
 
Avoid Use Of Global Variables [0205] High (750)
Global variables provide the opportunity for any part of a program to interact indirectly with any other part of a program via interactions on shared data. Even a small number of global variables can greatly increase the complexity of a program thereby increasing the learning curve for developers trying to understand the program.  
 
Complex Procedures Must Be Avoided [0130] High (750)
The cyclomatic complexity of a procedure gives a good indication of how easy a procedure is to understand, test and modify in the future. Ideally, the cyclomatic complexity of a procedure will be less than 10. Procedures with a cyclomatic complexity greater than 15 are generally too complex and should be simplified by splitting the procedure into separate procedures. The greater the complexity, the greater the testing effort required to ensure the procedure works correctly.  
 
Do Not Nest Select Statements Within Other Case Statement Blocks [0271] High (750)
To reduce code complexity and improve code readability avoid nesting Select...Case statements within other Case statement blocks. If the Case statement needs to perform conditional or complex logic this is best delegated to another function.  
 
Comments
Table Of Contents > Comments

Groups rules relating to the correct use of comments within source files.
 
Constant Declarations Must Include A Comment Header [0240] High (750)
All public and module-level constant declarations must include a standard comment header describing what the constant value represents and how it is to be used.  
 
Declare Statements Must Include A Comment Header [0243] High (750)
All Declare statements must include a standard comment header describing what the external function does as well as details of any arguments used and return values.  
 
Enum Definitions Must Include A Comment Header [0238] High (750)
All enum definitions must include a standard comment header describing what the enum represents and how it is to be used.  
 
Event Declarations Must Include A Comment Header [0242] High (750)
All event declarations must include a standard comment header describing the event, its arguments and the circumstances under which it is raised.  
 
Procedure Code Blocks Must Contain Comments To Describe Their Logical Operation [0244] Medium (500)
Code statements within procedures should be interspersed with comments to describe the logical operations being performed by the statement blocks. Comments should not not merely echo the physical code.  
 
Procedure Header Comments Must Be Correctly Formatted [0246] High (750)
Procedure header comments must take the following form: opening comment separator line, procedure name, created by, date created, one or more lines describing the procedure followed by individual argument names and descriptions, one or more lines of des