Visual Basic 6 Black Book
(Publisher: The Coriolis Group)
Author(s): Steven Holzner
ISBN: 1576102831
Publication Date: 08/01/98

Coding To Get The Most From Visual Basic

In this section, we’ll discuss some best practices coding for Visual Basic. All of these practices come from professional programmers, but of course whether you implement them or not is up to you. 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 a number of them. When it’s time to change your code, you just have to change the constant declaration in one place, not try to find all the magic numbers scattered around your code.

•  Be modular. Putting code and data together into modules 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 (and encapsulation in true OOP)—is the backbone of working with larger programs. Divide and conquer is the idea here.

•  Program defensively. An example of programming defensively would be to check data passed to you in a procedure before using it. This can save a bug from propagating throughout your program and 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. Debugging deeply nested conditionals 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 access procedures to protect sensitive data. (This is part of programming defensively.) Access procedures are also called Get/Set procedures, and they are called by the rest of the program when you want to work with sensitive data. If the rest of the program must call a Set() procedure to set that data, you can test to make sure that the new value is acceptable, providing a screen between that data and the rest of the program.

•  Ideally, variables should always be defined with the smallest scope possible. Global variables can create enormously complex conditions. (In fact, Microsoft recommends that global variables should be used only when there is no other convenient way to share data between forms.)

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

•  Use the & operator when linking strings and the + operator when working with numerical values. This is per Microsoft’s recommendations.

•  When you create a long string, use the underscore line-continuation character to create multiple lines of code. This is so 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."

•  Avoid using variants if you can. Although convenient, they waste not only memory but time. You may be surprised by this. Remember, however, that Visual Basic has to convert the data in a variant to the proper type when it learns what is required, and that conversion actually takes a great deal of time.

•  Indent your code with four spaces per Microsoft’s recommendations. Believe it or not, there have been serious studies undertaken here, and 2 to 4 spaces were found to be best. Be consistent.

•  Finally, watch out for one big Visual Basic pitfall: misspelled variables. Because you don’t have to declare a variable in Visual Basic to use it, you might end up surprised when Visual Basic creates a new variable after you’ve misspelled a variable’s name. For example, here’s some perfectly legal code modified from our tic-tac-toe project that compiles and runs, but because of a misspelling—xNoww for xNow—it doesn’t work at all:

   Private Sub Command_Click(Index As Integer)
       If xNow Then
           Command(Index).Caption = "x"
       Else
           Command(Index).Caption = "o"
       End If

       xNoww = Not xNow

   End Sub

Because Visual Basic treats xNoww as a legal variable, this kind of bug is very hard to find when debugging.

---

TIP:  Because Visual Basic auto-declares variables, it’s usually better to use variable names that say something (like intCurrentIndex) instead of ones that don’t (like intDD35A) to avoid declaring a variable through misspelling its name. A better idea is to use Option Explicit to make sure all variables must be explicitly declared.

---

If you work in teams, use version control. There are several well-known utilities that help programmers work in teams, such as Microsoft’s Visual SourceSafe. This utility, which is designed to work with programming environments like Visual Basic, restricts access to code so that two programmers don’t end up modifying independent copies of the same file.

That’s it for our best practices tips for now. We’ll see more throughout the book.

Getting Down To The Details

That completes our overview of topics common to the rest of the book. In this chapter, we’ve seen an overview of a Visual Basic project, including what goes into a project, how it’s stored on disk, and how the idea of scope works in a project. We’ve also seen a number of Visual Basic programming considerations, from naming conventions to best programming practices, including a list of Visual Basic-specific topics.

We’re ready for the rest of the book, and we’ll turn to the first natural topic now—the Visual Basic IDE.