Visual Basic —

Coding Conventions

This section outlines a number of conventions we have found useful when writing code. It isn't comprehensive-our in-house manual, VB Vogue, contains much more detail than we have space for here. We suggest you use this section as a basis for designing your own coding standards.

Principles

Always code for clarity, not efficiency. Choose variable and function names carefully. Be verbose rather than terse, and parenthesize expressions to make them clearer. Write your code for the reader.

Limit the scope of constants, variables, functions, and subroutines as much as possible. If you have the choice, always use a local object in preference to a global one.

Use explicit type conversions (CInt, CStr, and so on) when assigning between different variable types.

Some Specifics

Follow these guidelines when you write code:

  • Define all variables explicitly. Checking the Require Variable Declaration option under Tools/Options/Editor enforces this. Define variable-length arrays explicitly. (Visual Basic will not enforce this.)

  • Always specify the upper and lower bounds in an array definition.

  • Define constants, and use them in place of numbers in the code.

  • Always use the ByVal and ByRef keywords in parameter lists. Use ByVal where you have a choice.

  • Always use the Private keyword on functions and subroutines that are not exported from a module.

  • Define the types of all variables and function and subroutine parameters explicitly. For example, use Dim nBufSize As Integer instead of Dim nBufSize, and use Function nGetChars(nBufSize As Integer) As Integer instead of Function nGetChars(nBufSize).

  • Do not use implicit type suffixes (such as ! and &) in variable definitions.

  • In For loops, use Next <Index> instead of just Next.

Follow the general principle of restricting the scope of variables and functions to the barest minimum possible. However, be sure to use common sense. For example, a procedure that logically serves only one form should be "contained" within that form. Likewise, a procedure that could logically serve many forms should be placed in a module, even though it might currently be called only from one form.