10 Excel VBA Do’s and Don’ts
Here, you will find some advice you should take into account when you start developing your own Excel VBA solutions. Following these guidelines is no panacea to keep you out of (programming) trouble, but following them can help you avoid pitfalls that others have stumbled over.
Do declare all variables
How convenient it is: Simply start typing your VBA code without having to go through the tedious chore of declaring each and every variable you want to use. Although Excel allows you to use undeclared variables, doing so is simply asking for trouble.
The first commandment of VBA programming should be this:
Thou shalt declare every variable.
If you lack self-discipline, add an “Option Explicit” statement at the top of your modules. That way, your code won’t even run if it includes one or more undeclared variables. Not declaring all variables has only one advantage: You save a few seconds. But using undeclared variables will eventually come back to haunt you.
Don’t confuse passwords with security
Just password-protect the VBA project, and you’re safe, right? Wrong.
Using a VBA password can keep most casual users from viewing your code. But if someone really wants to check it, he’ll figure out how to crack the password.
Bottom line? If you absolutely, positively need to keep your code a secret, Excel isn’t the best choice for a development platform.
Do clean up your code
After your app is working to your satisfaction, you should clean it up. Code housekeeping tasks include the following:
Make sure every variable is declared.
Make sure all the lines are indented properly so the code structure is apparent.
Remove any debugging aids, such as MsgBox statements of Debug.Print statements.
Rename any poorly named variables. For example, if you use the variable MyVariable, there’s a pretty good chance that you can make the variable name more descriptive. You’ll thank yourself later.
Your modules probably have a few “test” procedures that you wrote while trying to figure something out. They’ve served their purpose, so delete them.
Add comments so you’ll understand how the code works when you revisit it six months from now.
Make sure everything is spelled correctly — especially text in UserForms and message boxes.
Check for redundant code. If you have two or more procedures that have identical blocks of code, consider creating a new procedure that other procedures can call.
Don’t put everything in one procedure
Want to make an unintelligible program? An efficient way to accomplish that is to put all your code inside one nice big procedure. If you ever revisit this program again to make changes, you’re bound to make mistakes and introduce some fine-looking bugs.
Do you see the problem? The solution is modular code. Split your program into smaller chunks, with each chunk designed to perform a specific task. After you pick up this habit, you’ll find that writing bug-free code is easier than ever.
Do consider other software
Excel is an amazingly versatile program, but it’s not suitable for everything. When you’re ready to undertake a new project, take some time to consider all your options. To paraphrase an old saying, “When all you know is Excel VBA, everything looks like a VBA macro.”
Don’t assume that everyone enables macros
As you know, Excel allows you to open a workbook with its macros disabled. In fact, it’s almost as though the designers of recent versions of Excel want users to disable macros.
Enabling macros when you open a workbook from an unknown source is not a good idea, of course. So you need to know your users. In some corporate environments, all Microsoft Office macros are disabled, and the user has no choice in the matter.
One thing to consider is adding a digital signature to the workbooks that you distribute to others. That way, the user can be assured that the workbooks actually come from you and that they haven’t been altered. Consult the Help system for more information about digital signatures.
Do get in the habit of experimenting
Setting up simple experiments is almost always much more efficient than incorporating a new idea into your existing code without understanding what those experiments bring.
Don’t assume that your code will work with other Excel versions
Currently, at least five versions of Excel are commonly used around the world. When you create an Excel app, you have absolutely no guarantee that it will work flawlessly in older versions or in newer versions. In some cases, the incompatibilities will be obvious. But you’ll also find that things that should work with an earlier version don’t work.
Excel includes a handy compatibility checker (choose File → Info → Check For Issues → Check Compatibility), but it only checks the workbook and ignores the VBA code. The only way to be sure that your application works with versions other than the one you created it with is to test it in those versions.
Do keep your users in mind
If you develop apps for others, your job is more difficult because you can’t make the same types of assumptions as you do when you develop for yourself.
For example, you can be more lax with error handling if you’re the only user. If an error crops up, you’ll have a pretty good idea where to look so you can fix it. If someone else is using your app and the same error appears, he or she will be out of luck. And when you’re working with your own application, you can usually get by without instructions.
You need to understand the skill level of those who will be using your workbooks and try to anticipate problems that they might have. Try to picture yourself as a new user of your application, and identify all areas that may cause confusion or problems.
Don’t forget about backups
Nothing is more discouraging than a hard drive crash without a backup. If you’re working on an important project, ask yourself a simple question: “If my computer dies tonight, what will I have lost?” If your answer is more than a few hours of work, you need to take a close look at your data back-up procedure. You do have a data back-up procedure, right?