Coding to Get the Most from Visual Basic

In this section, we'll discuss some of the best coding practices for Visual Basic. All of these practices come from professional programmers, but whether you implement them or not is up to you, of course. Here we go.

Avoid "magic numbers" when you can. A magic number is a number (excluding 0 or 1) that's hardwired right into your code like this:

Function blnCheckSize(dblParameter As Double) As Boolean

    If dblParameter > 1024 Then
        blnCheckSize = True

    Else
        blnCheckSize = False

    End If
End Function

Here, 1024 is a magic number. It's better to declare such numbers as constants, especially if you have several of them. When it's time to change your code, you just have to change the constant declaration in one place, instead of trying to find all the magic numbers scattered around your code.

Be modular. Putting code and data together into modules and classes hides it from the rest of the program, makes it easier to debug, makes it easier to work with conceptually, and even makes load-time of procedures in the same module quicker. Being modular, also called information-hiding or encapsulation in OOP, is the backbone of working with larger programs. Divide and conquer is the idea here.

Program defensively. For example, check data passed to you in a procedure before using it. This can save a bug from propagating throughout your program, and also help pinpoint its source. Make no assumptions.

Visual Basic procedures should have only one purpose, ideally. This is also an aid in larger programs when things start to get complex. Certainly if a procedure has two distinct tasks, consider breaking it up.

Avoid deep nesting of conditionals or loops, because debugging them visually is very, very inefficient. If you need to, place some of the inner loops or conditionals in new procedures and call them. Three levels of nesting should be about the maximum.

Use property procedures to protect sensitive data (this is part of programming defensively). Property procedures are called by the rest of the program when you want to work with sensitive data, and provide an interface to that data.

Ideally, variables should always be defined with the smallest scope possible. Global variables can create enormously complex conditions.

Do not pass global variables to procedures; if you do, the procedure you pass that variable to might give it one name (as a passed parameter) and also reference it as a global variable, which can lead to some serious bugs, because now the procedure has two different names for the variable.

When you create a long string, use the underscore line-continuation character to create multiple lines of code so that you can read or debug the string easily. For example:

Dim Msg As String
Msg = "Well, there is a problem " _
& "with your program. I am not sure " _
& "what the problem is, but there is " _
& "definitely something wrong."

Microsoft recommends that you indent your code with 4 spaces (believe it or not, there have been serious studies undertaken here, and 2–4 spaces was found to be best). But at least be consistent.

If you work in teams, use version control. There are several well-known utilities that help programmers work in teams, and you can integrate such utilities into VB .NET. The enterprise edition of Visual Basic comes with Visual SourceSafe, which is perfect for this purpose.

And that's enough overview—it's time to start creating Visual Basic programs and seeing what goes into the process. Let's get to some working programs now in Chapter 2.