It is also helpful if variable names indicate the type of data stored in the variable. Variable names such as strUserLastName indicate not only that the variable stores the user’s last name but also that this name is made up of string data. This type of naming scheme is commonly referred to as Hungarian Notation.

Note

The term “Hungarian notation” was coined in honor of former Microsoft Distinguished Engineer Charles Simonyi, who first proposed this method of naming variables. The term was chosen both in deference to Simonyi’s Hungarian nationality and to the fact that resulting variable names — such as strUserLastName — did not always resemble English. The Hungarian Notation used in this chapter has been slightly modified from the original version to better meet the needs of script writers.

Hungarian notation is based on the premise that the name of a variable should tell you everything you need to know about that variable. In addition to describing the purpose of the variable, variable names have a prefix that indicates the type of data that the variable holds. This is especially important with VBScript because VBScript is a typeless language: VBScript variables can hold any type of data, making it easy to inadvertently store the wrong data in a variable.

For example, by looking at the variable named UserID, you cannot tell whether a value such as ACCT-1005 is a valid ID. If UserID can contain string data, ACCT-1005 might be valid. If UserID can contain only numeric data, however, ACCT-1005 is not valid.

By adding a prefix that indicates the type of data stored in the variable, you can more easily identify problems that occur when the wrong type of data is stored in a variable. Because VBScript is a typeless language, nothing prevents you from storing an improper value in the variable. However, when you are debugging a script that is not working properly, noticing that a variable named intUserID has the value ACCT-1005 immediately provides at least one reason why the script is not working. Assigning improper data types to a variable also causes problems when dealing with databases, which typically require the correct data type, and when carrying out mathematical equations, date conversions, or other functions that require specific kinds of data.

When naming variables using Hungarian Notation, format the variable names using Camel casing. With Camel casing, the first part of the variable name (the prefix that indicates the data type) should begin with a lowercase letter. All subsequent words in the name then begin with an uppercase letter. Consequently, variables have names such as intUserID and strUserLastName rather than IntUserID or struserlastname.

Table 18.2 lists various data subtypes recognized by VBScript, as well as the recommended prefix for variables designed to store each kind of data.

Both Hungarian notation and Camel casing provide basic rules for creating variable names. In addition to these fundamental principles, some other suggested guidelines for naming variables in VBScript are listed in Table 18.3.

For the most part, you should not reuse variables during the execution of a script; each variable should represent only one item. For example, the following script code is valid. However, using the variable strName to represent, at various times, the user’s first name, the user’s middle initial, and the user’s last name causes confusion.

strName = "Robert"
strName = "M."
strName = "Smith"

To lessen confusion, use separate variables to represent each piece of data, as shown in the following script snippet. The code is easier to read and maintain, and there is no appreciable performance penalty for using three separate variables as opposed to reusing the same variable.

strFirstName = "Robert"
strMiddleInitial = "M."
strLastName = "Smith"

Theoretically, reusing variables can help conserve memory. In the preceding script snippet, the variables strFirstName, strMiddleInitial, and strLastName must all be held in memory at the same time, even if they are used just once and then discarded. However, the amount of memory saved by reusing the same variable as opposed to using three separate variables is negligible. Memory conservation is usually not an issue in system administration scripts.

Loop variables, such as those in a For-Next loop, are an exception to this rule about never reusing variable names. Many script writers use i as the primary loop variable in scripts; additional, nested, loop variables take the values j, k, l, m, and so on. For example, the following script code includes two separate loops, both of which use i as the loop variable:

For i = 1 to 10
    Wscript.Echo i
Next

For i = 1 to 10
    intTotalCount = intTotalCount + i
Next
Wscript.Echo intTotalCount

VBScript provides multiple ways to call functions and procedures. Some require parentheses around parameters; others do not. This is important, because improperly called functions and procedures can either result in errors within the script or, perhaps worse, cause subtle changes that affect the data returned by the script.

Valid ways of calling functions and procedures and passing parameters are shown in Table 18.5. For more information about passing parameters by value and by reference, see “VBScript Primer” in this book.

Note

Preparing for Visual Basic .NET. As shown in Table 18.5, the Call statement can be used with VBScript. Because Call is optional in VBScript, and because it cannot be used in Visual Basic .NET, it is recommended that you not use this statement when calling functions and procedures.

Calling functions and procedures in multiple ways can lead to considerable confusion and errors within the script. For example, an error occurs if you use a syntax that inadvertently passes a parameter by value when you intend to pass it by reference (or vice versa). To prevent problems with function and procedure calls, explicitly indicate the passing mechanism when writing the function or procedure. For example, the function shown in the following script snippet makes it clear that the parameter is being passed by value:

Function ConvertToFahrenheit(ByVal sngDegreesCelsius)
    ConvertToFahrenheit = (sngDegreesCelsius * (9/5)) + 32
End Function

As a general rule, pass parameters by value rather than by reference. Passing a parameter by value ensures that your function will not inadvertently change the value of that parameter. This is especially important if the parameter is required elsewhere in the script.

Note

Preparing for Visual Basic .NET. If you do not specify ByVal or ByRef when passing a parameter in Visual Basic .NET, the parameter is automatically passed by reference. This is different from previous versions of Visual Basic, in which the default mechanism for passing parameters is by value. To help make your intention clear, explicitly indicate the passing mechanism for all functions and procedures.

A blank space before and after each operator makes your code more readable. In most scripting languages, scripts run regardless of whether or not you put spaces before or after operators; however, the additional blank spaces generally make the script easier to read. For example, in the following line of VBScript code, notice how the k in the variable intCheck tends to run together with the >= sign and the <> sign. In addition, it is hard to separate the >= sign from the – sign that precedes the 3.

If intCheck>=-3 and intCheck<>7 then

Adding spaces before and after each operator makes the code easier to read and understand:

If intCheck >= -3 and intCheck <> 7 then

To further enhance readability, you might also enclose the If Then criteria in parentheses. In addition to enhancing readability, parentheses help enforce the order of precedence when using a conditional statement; the parentheses ensure that these statements are properly evaluated before the script takes any further action. Although parentheses are not required, they also make it easier to see the conditions being evaluated:

If (intCheck >= -3) and (intCheck <> 7) then

System administration scripts, including many WMI scripts that either create new items or reconfigure existing items, require you to supply parameters in a specific order. In many cases, this poses no problem. For example, in this hypothetical script, it is clear that the first parameter is “Large”, the second parameter “Heavy”, and the third parameter “Red”:

objThing.Change("Large","Heavy","Red")

But what if you want to change only the third parameter? In a situation such as that, you typically leave the first two parameters blank. When you do that, you must include two commas, making “Red” the third parameter:

objThing.Change(,,"Red")

When constructing parameter lists such as this, it is a good idea to put blank spaces before or after commas. In the following script, it is difficult to tell how many commas precede the value True. This is important in this example because each comma represents a placeholder for a service parameter, and True must be the sixth item in the list.

Set objServiceList = GetObject("winmgmts:").InstancesOf("Win32_Service")
For Each strService in objServiceList
    Return = strService.Change(,,,,,True,,,,,,)
Next

The commas are easier to count when separated by blank spaces, as shown in the following script snippet:

Set objServiceList = GetObject("winmgmts:").InstancesOf("Win32_Service")
For Each strService in objServiceList
    Return = strService.Change( , , , , , True , , , , , , )
Next

Control structures are coding conventions that determine the flow of a script. For example, If Then is a control structure because the flow of the script hinges on this structure: If the condition is True, the script branches in one direction; if it is False, the script branches in another direction.

Indentation is commonly used with control structure statements such as If Then and For Next. For example, the syntax shown in the following snippet is valid, but it is difficult to understand what the script is doing without reading the code several times and mentally tracing the program flow.

For Each strEvent in objInstalledLogFiles
If (strEvent.EventCode >= "529") and (strEvent.EventCode <= "539") Then
If (strEvent.EventCode <> "538") Then
intEventTotal = intEventTotal +1
End If
End If
Next

Compare that with the revised code shown in the following script snippet. This is the same code, but each new control structure statement is indented four spaces.

For Each Event in InstalledLogFiles
    If (strEvent.EventCode >= "529") and (strEvent.EventCode <= "539") Then
        If (strEvent.EventCode <> "538") Then
            intEventTotal = intEventTotal +1
        End If
    End If
Next

The indentation makes it easier to understand when each block of code runs. In the preceding example, you can see that the first If Then section runs only for events with an EventCode of 529 through 539. The nested If Then statement, which adds up the total number of events, runs only if the EventCode does not equal 538. Thus, the script tallies all the events with the EventCode 529, 530, 531, 532, 533, 534, 535, 536, 537, or 539. An event with the EventCode 538 is not included in the tally.

It is also recommended that you use indentation in all major sections in your scripts, including functions and procedures. As a rule of thumb, use four spaces for each indent; in some cases, identifying passages indented less than four spaces is difficult, while indenting more than four spaces usually creates more empty space than needed. For example, indent a function as follows:

Function ConvertToMiles(ByVal sngKilometers)
    ConvertToMiles = sngKilometers * 2.2
End Function

When formatting control structure code, be sure that you align all the control structure statements (such as Do and Loop). In the following example, the If, ElseIf, Else, and End If statements are all aligned. Alignment clearly indicates that three possible values for the variable strState are being evaluated.

If (strState = "WA") Then
    intStateIDNumber = 1
ElseIf (strState = "OR") Then
    intStateIDNumber = 2
Else
    intStateIDNumber = 3
End If

In addition, use spaces rather than tabs when indenting statements. Some text editors use different tab formats than others; as a result, your carefully aligned code might look quite different when viewed by someone using a different editor.

Although many scripting languages allow you to place multiple statements on a single line, this can be confusing to anyone reading your script and should be avoided. For example, using VBScript you can place multiple statements on a single line by separating each statement with a colon. The following code sample shows four statements included on a single line of code:

For i = 1 to 100 : intTotal = intTotal + i : Next : Wscript.Echo intTotal

This code is valid, but the purpose of the script is not readily apparent. In fact, although it appears far more complicated, this script merely adds the integers from 1 to 100 and then echoes the result. The purpose is more apparent when each statement is placed on a separate line and formatted according to previous recommendations:

For i = 1 to 100
    intTotal = intTotal + i
Next
Wscript.Echo intTotal

VBScript allows you to place If Then statements on a single line, a shortcut method that can save a few keystrokes when writing a script. However, the time saved writing the script could result in additional time required for someone editing your script, because single-line If Then statements are often hard to read. For example, determining the purpose and possible variable values is difficult in this line of code:

If (intDept = 1) Then strDepartment = "Accounting" Else strDepartment = "Other"

By comparison, the multiline If Then statement in the following script snippet clearly shows the purpose of the script: check the value of the variable intDept, and use that result to set the value of the variable strDepartment.

If (intDept = 1) Then
    strDepartment = "Accounting"
Else
    strDepartment = "Other"
End If

By avoiding single-line If Then statements, you also facilitate using statement blocks such as If End If and Do Loop. One common scripting mistake is to start a statement block but then fail to end it, such as using an opening statement like For i = 1 to 100 without using a closing statement such as Next.

Note

Preparing for Visual Basic .NET. Single-line If-Then statements are not allowed in Visual Basic .NET. In Visual Basic .NET, you must use multiple-line If-Then statements.

To help other administrators who maintain or modify your scripts, limit each individual script to a single scripting language. Windows Script Files provide a way to use multiple scripting languages within a single script; for example, you can write a script that carries out one function in VBScript, a second function in JScript®, and a third in any other registered ActiveX® scripting language. Although this provides considerable flexibility, anyone who maintains your script must be proficient in each of these languages. Use additional languages only if you cannot perform those operations any other way.

Note

Preparing for Visual Basic .NET. Windows Script Files can be used with Visual Basic .NET, but only if all the jobs specified in the file use the same scripting language. Windows Script Files using multiple languages are not allowed.

VBScript is a case-insensitive language; this means that you can type keywords and statements in uppercase, lowercase, or any combination without generating a syntax error. For example, the four case styles shown in the following are all syntactically equivalent:

wsCRIpt.EchO "This is a valid VBScript statement."
wSCRIPt.eCHo "This is a valid VBScript statement."
WSCRIPT.ECHO "This is a valid VBScript statement."
Wscript.Echo "This is a valid VBScript statement."

Although the four styles are syntactically equivalent, some are definitely easier to read than others, and the combination of the four different styles results in a document that is difficult to read. To enhance readability, type VBScript keywords, statements, and other elements using Pascal casing. To use Pascal casing, begin each individual word with an uppercase letter, and type remaining letters in lowercase. This is not only easier to read but also helps distinguish the VBScript elements from the rest of the text.

In the following script snippet, Pascal casing is used to distinguish keywords from variables and constants:

Const MANAGER_JOB_TITLE_ID = 100
Select Case
Case strDepartment = "Accounting"
    If intJobTitle = MANAGER_JOB_TITLE_ID Then
        intRatingScale = 1
    Else
        intRatingScale = 2
    End If
Case strDepartment = "Administration"
    intRatingScale = 1
Case Else
    intRatingScale = 2
End Select

Compared with programming languages such as C and C++, the syntax of scripting languages is almost conversational. Scripting languages allow you to write your script in a fashion somewhat similar to ordinary speech. You should take advantage of this when writing scripts and try to mimic typical conversational patterns and syntax whenever possible. This makes your scripts easier to read and understand because the code appears more like ordinary language than computer programming.

Note

Brian Kernighan, author of a number of books on programming style and programming conventions, refers to this as the “telephone test.” He believes you should attempt to read your code to someone over the telephone. If the person on the other end does not understand what you are talking about, then you need to rewrite your code.

For example, consider the phrasing of If Then statements in your scripts. In conversation, people generally phrase these statements positively. Suppose that stores in the state of Washington charge a special sales tax to residents of the state but not to residents of other states. If you are a store owner in Washington, you would likely to explain your store’s sales tax policy by saying, “If the customer is from Washington state, then we charge them sales tax. Otherwise, we do not.”

Your If Then statements should use a similar syntax. For example, the following script uses valid VBScript syntax but is awkward to read (try reading it out loud):

If (Not State = "WA") Then
    SngSalesTax = 0
End If

A grammatical construction such as If Not State Equals Washington causes confusion. Instead of testing for the negative condition, test for the positive condition, as shown in the following snippet. Read this script aloud, and notice that it sounds less awkward.

If (State = "WA") Then
    SngSalesTax = .065
End If

Or you might use the does not equal (<>) operator:

If (State <> "WA") Then
    SngSalesTax = 0
End If

When checking the value of a Boolean (True/False) expression, script writers often use a syntax such as this:

If blnIsUSCitizen = True Then
    Wscript.Echo "This person is a citizen."
Else
    Wscript.Echo "This person is not a citizen."
End If

On the surface, this statement appears to pose no problems. In reality, however, a statement like this can return the value False even when the expression is actually True. This is because VBScript sets the value of True to –1, while most programming languages set the value of True to 1. As a result, the following situation can occur:

To avoid this problem, use syntax similar to that shown in the following script snippet. In this case, the statement “If blnIsUSCitizen Then” is used as the condition. This statement translates as, “If blnIsUSCitizen equals anything other than 0.” Because 1 is not 0, the condition is correctly interpreted as being True.

If blnIsUSCitizen Then
    Wscript.Echo "This person is a citizen."
Else
    Wscript.Echo "This person is not a citizen."
End If

By contrast, False is always assigned 0. When you check for a False value, you can look for either False or for 0. For the sake of consistency, however, it is generally best to test for False as shown in the following snippet:

If blnIsUSCitizen = False Then
    Wscript.Echo "This person is not a citizen."
Else
    Wscript.Echo "This person is a citizen."
End If

Parentheses serve two purposes in mathematical equations: they force the order of arithmetic precedence, and they enhance readability. These two functions are illustrated in the following script snippet. This script works as expected: It multiplies the regular price of an item by the tax rate, multiplies the standard discount rate by a preferred customer rate, and then subtracts the total discount from the total regular price. However, the equation is somewhat difficult to read, and the fact that it works is, in part, an accident: The different terms and operators used in the equation just happen to be arranged in a way that respects the order of precedence.

RegPrice = 100
Discount = 5
SalesTax = 1.05
PreferredCustomer = 2
Wscript.Echo RegPrice * SalesTax - Discount * PreferredCustomer

Although the equation works as expected, someone editing the script might have difficulty understanding how the calculation works. If so, he or she might try to group the items within parentheses. If those parentheses are misplaced, the equation yields unexpected results. For example, one placement produces a correct answer, but another placement produces an incorrect answer:

To avoid problems such as this, always use parentheses when performing calculations that have the following characteristics:

A revised version of the script, which groups the items into logical sets, is shown in the following snippet:

RegPrice = 100
Discount = 5
SalesTax = 1.05
PreferredCustomer = 2
Wscript.Echo (RegPrice * SalesTax) - (Discount * PreferredCustomer)

Automation objects often have default properties associated with them. A default is simply the property that is used unless a different property is specified. For example, in WSH the Arguments object has the default property Item. In VBScript, you can omit the property name when working with the default property of an item. Thus, you can write the following script to cycle through the arguments passed to that script:

Set objArgs = WScript.Arguments
For i = 0 to objArgs.Count - 1
     WScript.Echo objArgs(i)
Next

Although VBScript allows you to omit default properties, it is a good idea to always include the default property name as part of your script. This makes your code easier to read and understand, especially if you are working with an automation object whose default property is not widely known. To ensure that there is no doubt as to which property is being employed, you should use code similar to this, which clearly specifies the default property Item:

Set objArgs = WScript.Arguments
For i = 0 to objArgs.Count - 1
   WScript.Echo objArgs.Item(i)
Next

Note

Preparing for Visual Basic .NET. Default properties are not supported in Visual Basic .NET. In Visual Basic .NET, you must always specify the property name.

Comments are statements that are ignored by the script host when the script runs. To ensure that the script host does not attempt to interpret a comment as a command, you must preface each comment with a comment delimiter. VBScript allows two delimiters: the single quotation mark (’) and the REM statement. For example, both of the following lines of code are valid comments:

' This is a comment using a single quote delimiter.
REM This is a comment using the REM statement as a delimiter.

Although most script writers use the single quotation mark, you might consider following the single quotation mark with an asterisk when commenting your code:

'* This is another comment.

This approach has two advantages over the single quotation mark alone. First, it makes the comment stand out from the rest of the text; a single quotation mark by itself can be difficult to see at times. Second, the single quotation mark is a valid VBScript character that has uses beyond delimiting comments. This can be a problem if you use an automated procedure to extract comments from a script; such a procedure might also retrieve items that are not comments. Because you are less likely to use ’* anywhere else in your script, it makes a good delimiter.

Always include comments on separate lines except for comments that accompany the declaration of a variable. Comments included on the same line as a VBScript statement (end-of-the-line comments) are valid but can be difficult to read. For example, compare the two commenting styles in the following script snippet; in the first half of the script, comments are placed on the same line as a VBScript statement, while in the second half of the script, the comments are placed on separate lines. Most people find it easier to quickly identify the comments used in the second half of the script.

On Error Resume Next
Set WshNetwork = WScript.CreateObject("WScript.Network")
WshNetwork.MapNetworkDrive "Z:", "\RemoteServerPublic" '* Map drive Z.
If Err.Number <> 0 Then '* Check to make sure the operation succeeded.
    Err.Clear
    Wscript.Echo "The drive could not be mapped."
End If

'* Map drive Z.
WshNetwork.MapNetworkDrive "Z:", "\RemoteServerPublic"

'* Check to make sure the operation succeeded.
If Err.Number <> 0 Then
    Err.Clear
    Wscript.Echo "The drive could not be mapped."
End If

In many scripting books, comments are set off from the rest of the text by use of a frame (typically a box drawn with asterisks). These frames make it easy to identify the comments; however, the frames themselves can be difficult to maintain. For example, consider the frame used to surround the comments in this script snippet:

'***************************************************************************
'*   This is a comment enclosed within a frame. These frames might look    *
'*   nice, but they can be difficult to maintain.                          *
'***************************************************************************

Although the frame might have a certain aesthetic appeal, if you edit the comment, the line lengths will change and the frame might look like this:

'***************************************************************************
'*   This is a comment enclosed within a frame. Frames might look    *
'*   nice, but they are difficult to maintain.                          *
'***************************************************************************

If you like the idea of clearly delineating comments, you might want to use only a top and bottom border instead of a complete frame, as shown in the following snippet. The comments are still easy to identify, but the frame requires less maintenance.

'**************************************************************************
'*   If you feel the need to include a frame of some kind, just use a
'*   border on the top and bottom. This is much easier to maintain.
'**************************************************************************

Whenever you document something, it is a good idea to make clear what you are documenting; do not require readers to read the entire manual to determine whether this really is the information they are looking for. The same is true of scripts. If your scripts are shared with others, it is strongly recommended that you include information about the script, and that you include it at the very beginning of the script in the form of a script header.

Script headers are a collection of comments that explain the purpose and history of a script. Script headers detail such things as:

For example, an organization might use the following standard script header:

'* Script name:   NewUsers.vbs
'* Created on:    8/15/2000
'* Author:        Ken Myer
'* Purpose:       Creates new user accounts and new Exchange 2000 mailboxes.
'*                Adds new users to security groups based on job title and
'*                department.
'* History:       Pilar Ackerman 10/15/2000
'*                Modified to reflect new area code.

Simply by reading the header, you can tell what a script does, when it was written, how often it has been modified, and who to contact if you have questions about the script or the script code.

Each function and procedure in a script should also have a header that describes the purpose of that function or procedure. Information typically included in a function or procedure header is shown in Table 18.6.

A sample function header might look like this:

'* Function Name:           CalculateTotalPay()
'* Purpose:                 Calculates total pay for an employee based on
'*                          current salary plus merit increase.
'* Arguments supplied:      intUserIDNumber, curCurrentSalary, intMeritRank
'* Return Value:            curRevisedSalary
'* Function is called by:   SalaryAdjustment
'* Function calls:          ConvertMeritRank

Scripts are often short pieces of code designed to carry out a single function. Because of this, formal documentation is not always required; the script comments usually provide sufficient information for anyone using the script. For longer scripts, however, it might be useful to provide separate documentation rather than requiring users to read through the script, searching for comments.

Well-commented scripts can actually help you write the documentation for your scripts. By including comments such as who wrote the script, when it was written, why it was written, and the purpose of procedures and functions, you already have much of the written documentation for the script as well. You only need to copy those comments from the script to the script documentation.

One way to create separate documentation for a script is to use an automated procedure to extract the comments. These comments can then serve as the basis for the written documentation. For example, the script shown in Listing 18.2 extracts comments by doing the following:

 1 Const ForReading = 1
 2 Const ForWriting = 2
 3 Set objFSO = CreateObject("Scripting.FileSystemObject")
 4 Set objScriptFile = objFSO.OpenTextFile _
 5     ("c:scriptsService_Monitor.vbs", ForReading)
 6 Set objCommentFile = objFSO.OpenTextFile("c:scriptsComments.txt", _
 7     ForWriting, TRUE)
 8 Do While objScriptFile.AtEndOfStream <> TRUE
 9     strCurrentLine = objScriptFile.ReadLine
10     intIsComment = Instr(1,strCurrentLine,"'*")
11     If intIsComment > 0 Then
12         objCommentFile.Write strCurrentLine & VbCrLf
13     End If
14 Loop
15 objScriptFile.Close
16 objCommentFile.Close

If you have ever written a lengthy report or memorandum, you might have found it useful to type notes to yourself as you worked on the document. For example, you might have typed something such as, “Need to add a section here about the budget problems from a year ago” or “These two paragraphs need to be rewritten.” Notes such as these are useful reminders and also serve as a sort of status report, letting you know what is and is not working, and how you are progressing.

Comments allow you to put this same type of status report in scripts still in development. For example, suppose you are working on a script and you encounter a problem. If you are unable to immediately solve the problem, insert a comment labeled BUG to indicate that this section of code needs further work. The next time you work on that script, search for BUG to locate any sections of the code that are not working properly. If you are able to fix the problem, remove the BUG comment.

For example, you might use the following comment labels:

The following script snippet illustrates comments used as a debugging aid.

'* BUG (DMS 3/10/02)    This should loop through all 100 sales districts,
'* BUG (DMS 3/10/02)    calling the function RetrieveInformation for each one,
'* BUG (DMS 3/10/02)    but it only does the first 90 sales districts and then
'* BUG (DMS 3/10/02)    stops.

For i = 1 to 100
    RetrieveInformation(i)
Next

The debugging comments in the preceding snippet include the reviewer’s initials and the date the comment was added. This facilitates communication between the script writer and the reviewer. In addition, it helps ensure that no unneeded comments are left in the finished code; a debugging comment added years earlier is unlikely to still be valid and should be deleted.

 1 Const ForReading = 1
 2 Const ForWriting = 2
 3 Set objFSO = CreateObject("Scripting.FileSystemObject")
 4 Set objTextFile = objFSO.OpenTextFile("C:ScriptsCreateUser.vbs", ForReading)
 5 Do While objTextFile.AtEndOfStream <> true
 6     strNextLine = objTextFile.Readline
 7     intCheckForBugComment = Instr(strNextLine, "'* BUG")
 8     If intCheckForBugComment = 0 Then
 9         strSavedLines = strSavedLines & strNextLine & VbCrLf
10     End If
11 Loop
12 Set objTextFile = objFSO.OpenTextFile _
13     ("c:scriptsCreateUser.vbs" , ForWriting)
14 objTextFile.Write strSavedLines
15 objTextFile.Close