Professional Documents
Culture Documents
Make sure you log any requirements that aren't met, and/or display descriptive error messages.
If your function or subroutine receives parameters, use distinctive parameter names to avoid
conflicts with global variables. Do not use an existing variable name for a parameter name.
As you may have noticed, I use the prefix my for parameter names in my own scripts. Choose any
naming system you want, but be consistent, and keep in mind that some day others may need to
understand your code.
Experiment with Denis St-Pierre's ByVal/ByRef test script to become familiar with the concepts.
You may have noticed that many scripters use the first character, or the first 3 characters, of
variable names to specify the data type: objFSO for a (FileSystem) object, intDaysPerWeek for
integers, etc.
Though in VBScript any variable can contain any type of data at any time, this naming
convention helps make clear what type of data a variable is supposed to contain.
For function or subroutine that receive parameters, use distinctive parameter names to avoid
conflicts with global variables. Using existing variable names for parameter names spells trouble.
As you may have noticed, I use the prefix my for parameter names in my own scripts. You can
choose any naming system you want. But do keep it consistent.
Keep in mind that some day others may need to understand your code.
to prevent changing the value of an existing global variable named varParameter in the global
scope.
I urge you to try Denis St-Pierre's ByVal/ByRef test script to build an understanding of the
concepts.
It may save you days of stressful debugging.
Initialize variables
This may be important when you use loop counters other than For loops: make sure the counter
variable has a valid value to start with.
Also watch out for global variables that are used in subroutines or functions.
Now, if the code doesn't do what it is supposed to do, you can have a look at the intermediate
results to check where the problem lies.
Write every detail in a log file too, preferably with a timestamp in order to detect possible delays.
If subroutines or (user defined) functions are used, log each call to these subroutines, it will help
you follow the program flow.
If I expect problems with a script, I often add an optional /DEBUG command line switch, which
will tell the script to log even more details.
Create and use a debug window
This is a trick I learned from Don Jones, who describes it in his book VBScript, WMI, and ADSI
Unleashed: Using VBScript, WMI, and ADSI to Automate Windows Administration.
Dim objIEDebugWindow
objIEDebugWindow.Document.Body.InnerHTML = _
objIEDebugWindow.Document.Body.InnerHTML _
& myText & "<br>" & vbCrLf
End Sub
objIEDebugWindow must be declared in the main script body, not in the subroutine
Notes: (1)
(must be global)!
Do not discard the objIEDebugWindow object at the end of the script, or your debug
(2)
window will vanish!
There are several VBScript aware editors (IDEs) available, some with built-in debugger. The
main advantages of these editors are:
Different colors for commands and keywords: a typo will result in the wrong color
IntelliSense ™ like "intelligence" and object browser: type a dot after an object name and
you'll get a drop-down list of avaialble properties and methods
Built-in debugger: run the script "inside" the editor, add breakpoints, monitor variable
values, get improved error handling
My personal favorite is VbsEdit, which saves me a lot of time and frustration when writing in
VBScript.
Because there are more editors and more scripting languages, I compiled a list of script editors
and IDEs.
In short, describe it as a "black box": what goes in, what comes out, and how are the two related.
Insert a line On Error Resume Next just before some code that might cause trouble.
Insert another block of code after that suspect code to deal with potential errors.
Use Err or Err.Number and Err.Description to detect and log and maybe even correct errors.
If no more problems are expected, insert a line On Error Goto 0 after the custom error
handling code to restore the default built-in error handling.
If Err Then
WScript.Echo "Error # " & Err.Number
WScript.Echo Err.Description
' take some action, or in this case, abort the script with return code 1
WScript.Quit 1
End If
Clean up
It is usually advisable to clean up any leftover objects at the end of the script.
Objects like the FileSystem object, Internet Explorer and others may cause memory leaks if they
aren't discarded and new instances are being opened all the time.
Just make sure to add a Set objectName = Nothing line at each "exit" (just before each
WScript.Quit) and end of the program flow.
Objects that are "created" inside a subroutine or function should always be discarded at the end
of the routine.
A known exception to this rule is the Internet Explorer Debug Window discussed before.
Check the WSH version
Ok, so you wrote your script, tested it on your own computer, maybe even on multiple computers,
and everything seems to work fine.
Does that mean your script is ready to be distributed?
Browse through your script and for each command you used, look up the WSH version required
in MSDN's VBScript Version Information tables (JScript Version Information is available too).
The WSH version required for a particular command can be found in the page's second table.
Besides using the MSDN links above, you can also use the WSH documentation in .chm
Note:
format
In case you aren't sure about the client computers, you can make your script itself perform a
check, using:
Debuggers that can be used for VBScript include (but are, most likely, not limited to):