Standards That Change the Way You Program

Meaningful, substantive standards—standards that can genuinely improve program quality—are radical and modern, but I believe that they are in tune with the future direction of the development of the Visual Basic language.

For those of you in a hurry, I’ll tell you the ending. Here are the standards. The rest of this chapter discusses the background to these and has plenty of interesting gems in it. But if you want, you can just go ahead and use these standards for a while. If you find that you’re thinking more, typing less, and producing better code as a result, why waste time on the theory—it’s the practice that counts.

• Rule 1: Do not use global variables. And I mean no globals! No exceptions are allowed. You can always accomplish the same result without a global variable. Later in this chapter, I explain why globals are bad, and I provide some examples of when Visual Basic programmers typically would use globals but needn’t. By global, I mean a variable with global scope. So I count as global anything prefixed with the Global keyword, or a Public variable in a regular module (BAS file).
  
  
• Rule 2: Do not use user-defined types. By this, I mean anything with the Type keyword. I don’t mean user-defined classes—you should have lots of those. The one exception to this is when you are calling into a DLL that requires a structure. Use them for this purpose alone.
  
  
• Rule 3: Do not pass function parameters by reference. Prefix all of your function parameters with ByVal. What a pity this isn’t the default parameter-passing convention—it would have saved a lot of typing.
  
  
• Rule 4: Do not use first-class data types—use Variants. This rule is the most controversial. I’m aware that this one challenges the perceived wisdom, but it is the one that pays the most dividends. You should replace all variables of type integer, long, single, double, byte, date, string, Boolean, and currency with Variants. Trust me.