Some developers argue that establishing standards for the way your team codes its Visual Basic programs hampers creativity. But in fact, it makes life easier for everyone on the team. In general, standards will make your programs more readily understood by your peers, and a good programming style allows for greater readability, faster debugging, and fewer defects. Let’s look at some suggested standards that you can apply to your code today. They will cover how to organize your modules, error handling, and some odds and ends.
Have you missed these previous articles on VB programming standards?
- "VB programming standards lead to better code"
- "Standards for menus and formatting make VB code more readable"
Organize with modules
I've seen a number of projects where all functions and procedures are stored in a single module. Modules should be used to organize and group related functions and procedures. If you have procedures related to database access, for example, put them in a separate module. Create a new module for any kind of functionality. It’s better to have more modules than less, because that helps you organize your procedures in a logical fashion. So, for instance, if I open up a project to modify some database-accessing functionality, I go straight to the module where that code is, and I don't have to look through the monstrous, 15-page module where the code for the whole project is. These little things are not hard to do. It is easy to create a new module to logically separate your code, but too often, programmers don’t do that.
Having a number of modules that are functionality-specific will also help you reuse that functionality in other projects. Instead of going through the single module filtering functions and procedures you need, you can simply copy a needed module to your new project.
None of this would be necessary if project requirements didn't change as often as they do. But since most of us have to make changes on a daily basis, it pays to spend a little time planning how to organize your code before you actually start typing.
Organizing your code will help you and other members of your team to make modifications in the future. When designing modules, consider the following:
- Always give procedures and modules descriptive names.
- Create specialized procedures/functions and modules.
Error handling allows you to keep your programs from crashing, and in an orderly fashion, to correct mistakes and notify the users that an error occurred.
Preferably, every procedure should have an error handler. Create central error handlers for your projects. Doing so takes time, but it’s more efficient than creating an error handler in each procedure. For example, if you create a procedure to show errors in a consistent format throughout an application called ShowError, you just have to call ShowError in each procedure in your error-handling label instead of rewriting the code of ShowError every time. Further, a central error handler allows you to create additional features, such as logging all your errors to a text file for future reference. This can be very useful when it comes to debugging.
So for all your projects, create a central procedure named something like ShowError to which you can pass the form and subroutine where the error occurred, the error number, and description. In the ShowError procedure, which should be accessible from any form and module, write the code to display an error message and log the error to a text file.
When you show the message box with the name of the error, make sure to also provide a description of the error and specify who to contact when a specific error occurs. Also, try to make the error messages friendly. Sometimes you can simply use the error object's own properties such as a number, source, and description, but if you know that in some specific cases a specific error may come up, you may substitute the description with your own text to make it more meaningful.
Here are some odds and ends that can further improve your team’s work.
If you use abbreviations, make sure that they are consistent throughout the application. For example, using fcst and forecast interchangeably leads to confusion. Pick one and stick with it.
Grouping variables and constants
Variables and constants should be grouped by function. All of VB's own constants used in an application should be grouped in a single module and separated from application-specific constants.
& and + operators
Always use the & operator when concatenating strings and the + operator when adding numeric values. Using the + operator on nonnumeric values can cause unexpected results.
Never use strings that stretch longer than you can fully see on your screen. Instead, use the underscore line-continuation character to create multiple lines of code so that you can easily modify it when necessary. This is useful when creating messages to be displayed in Message or Input boxes, as well as when using embedded SQL in your VB code.
Whenever you have to perform a repetitive task, you should create a loop to eliminate redundancy and to avoid writing the same code twice. If you did write the same piece of code twice and later had to make a change in it, you would have to make the change twice as well instead of just modifying the loop. Whenever you create a variable to be used as a counter in loops, avoid using it after the looping structure is closed. Don't mix loop-specific variables with other variables. This consistent use of variables will make the code easier to read.
If/Else and Select Case
If/Else and Select Case structures are used to control the code flow. However, at times, one is more appropriate than the other. If the condition you are checking evaluates to either True or False, then using an If/Else is appropriate. If the condition evaluates to a numerical value, If/Else may still be appropriate since VB will interpret it as True or False; all non-zero values are considered True, whereas all zero values are considered False. You should also use the If/Else when making a number of comparisons, but with unrelated conditions, looking at “age” and “income” for example.
If age-related-condition Then
Elseif income-related-condition Then
Use Select Case when comparing a non-Boolean expression to various possible values. You should always use Case Else when you use Select Case to make sure that a value can't slip through Select Case statements. If you are sure you have listed all possible results in your cases, you may still want to use Case Else to raise an error. That can be useful when future modifications by you, or others, result in a value that was never anticipated.
This would be the situation of evaluating the same condition with many possible outcomes:
Select Case strReportType
It all adds up
Grouping functions and adding a Case Else will not transform your code overnight. However, if you begin incorporating some of these best practices into your routine, you and your team will be the benefactors of greater efficiency, happier customers, and fewer headaches. Work with your teammates to come up with something that seems reasonable—something you all can live with. It’s worth the effort.