1. Keep the lines in your scripts short. You can string together multiple expressions in a single line, but if you do, it will make your scripts harder to read and debug. VBScript allows you to break lines with underscores, and conditional statements allow you to list conditions for executing code instead of crowding everything into a single line.
2. Comment liberally. Right now, you know what the statement you typed means. Will you know six months from now? Will someone else know after you're promoted? Don't guess. Make sure by spelling out what the pieces of a script are supposed to be doing. Commenting can also simplify debugging by specifying what code should be doing.
3. Mix the case in your code. I find mixed-case code easier to read. VBScript is case-insensitive for most purposes (one exception is when computing the ASCII character values for letters; upper-case letters have different ASCII values from lower-case letters), so you can usually make your code more readable without impacting its execution. If something is case-sensitive, I'll point it out.
4. Use the command-line executing environment whenever possible. WSH supports both a command-line interface and a graphical interface (the default). In the command-line interface, output appears in a command window unless you specifically send it to a dialog box. In the graphical interface, all output goes to message boxes. Some operations won't work in a graphical environment
5. Name variables according to their data type. Naming variables according to the kind of data they represent (e.g., giving strings names beginning with "s") will make code easier to debug. Some expressions will work differently -- or not work at all -- if they try to work with data of an unexpected data type.
6. Explicitly define variables. Although you can define variables implicitly by assigning values to them, it's better practice to use a Dim statement to define the variables that you will use in the script up front and to tell VBScript to disallow the use of any variables not predefined. Doing so will help you catch bugs introduced by mistyping variable names, because WSH will not let you use variables that aren't predefined.
7. Don't write scripts in a word processor and save the script as a text file. This may sound crazy, but people do it, and it can lead to errors in apparently flawless code. Scripts use a lot of quotation marks. If your word processor converts straight quotes to curly quotes, then when you copy the script to the ASCII text editor, junk characters -- that WSH cannot interpret -- will replace the converted quote marks. Just use a script editor or text editor from the beginning and life will be simpler.
Increase your scripting expertise
Arranging and manipulating data
Combining operators with functions
Simplify with subroutines
Where do objects come from?
Seven quick scripting tips
|ABOUT THE AUTHOR:|
When Christa Anderson began working with Windows Server operating systems in 1992, she became increasingly interested in finding more efficient and flexible ways of performing routine tasks. Christa has written extensively about administrative scripting and taught technical sessions on the subject at conferences such as Comdex and CeBIT, helping people who had never done any scripting to write their own scripts in half a day. In addition to her interest in scripting Windows management, Christa is an authority on server-based computing and the program manager for Terminal Services licensing in Longhorn. If you have a scripting question for Christa, please e-mail her at scripting@SearchWinSystems.com.