Datasheet

Chapter 1: A Quick Introduction to Programming

Always Favor the Explicit over the Implicit

When you are writing code, constantly ask yourself: Is my intent clear to someone reading this code?

Does the code speak for itself? Is there anything mysterious here? Are there any hidden meanings? Are

the variable names too similar to be confusing? Even though something is obvious in your mind at the

moment you are typing the code, it doesn’t mean it will be obvious to you six months or a year from

now — or to someone else tomorrow. Always endeavor to make your code as self-documenting as possi-

ble, and where you fall short of that goal (which even the best programmers do — self-documenting

code can be an elusive goal), use good comments to make things clearer.

Be wary of using too many generics in code, such as

x , y , and z as variable names and Function1 ,

Function2 , and Function3 as function names. Instead, make them explicit. Use variable names such as

UserName and TaxRate . When naming a variable, use a name that will make it clear what that variable

is used for. Be careful using abbreviations. Don’t make variable names too short, but don’t make them

too long either (10–16 characters is a good length, but ideal length is largely a matter of preference). Even

though VBScript is not case-sensitive, use mixed case to make it easier to distinguish multiple words

within the variable name (for example,

UserName is easier to read than username ).

When naming procedures, try to choose a name that describes exactly what the procedure does. If the

procedure is a function that returns a value, indicate what the return value is in the function name (for

example,

PromptUserName ). Try to use good verb–noun combinations to describe first, what action the

procedure performs, and second, what the action is performed on (for example,

SearchFolders ,

MakeUniqueRegistryKey , or LoadSettings ).

Good procedure names tend to be longer than good variable names. Don’t go out of your way to make

them longer, but don’t be afraid to either. Fifteen to thirty characters for a procedure name is perfectly

acceptable (they can be a bit longer because you generally don’t type them nearly as much). If you are

having trouble giving your procedure a good name, that might be an indication that the procedure is not

narrow enough — a good procedure does one thing, and does it well.

That said, if you are writing scripts for web pages to be downloaded to a user’s browser, it is sometimes

necessary to use shorter variable and procedure names. Longer names mean larger files to download.

Even if you sacrifice some readability to make the file smaller, you can still take time to create descriptive

names. With web scripts, however, you may encounter instances where you don’t want the code to be

clear and easy to understand (at least for others). You’ll look at techniques that you can employ to make

scripts harder for “script snoopers” to follow while still allowing you to work with them and modify

them later (see Chapter 17 ).

Modularize Your Code into Procedures,

Modules, Classes, and Components

As you write code, you should constantly evaluate whether any given code block would be better if you

moved it to its own function or subprocedure:

❑ Is the code rather complex? If so, break it into procedures.

❑ Are you using many Ands and Ors in an If...End If statement? Consider moving the

evaluation to its own procedure.

c01.indd 27c01.indd 27 8/27/07 7:45:27 PM8/27/07 7:45:27 PM