Using Subroutines and Functions in Microsoft VBScript
Before You Begin
To work through the material presented in this chapter, you need to be familiar with the following concepts from earlier chapters:
Reading text files
Writing to text files
Using the For...Next statement
Creating the Select Case statement
Connecting to Microsoft Active Directory directory service
Reading information from WMI
After completing this chapter, you will be able to:
Convert inline code into a subroutine
Perform Active Directory user management
Working with Subroutines
In this section, you’ll learn about how network administrators use subroutines. For many readers, the use of subroutines will be somewhat new territory and might even seem unnecessary, particularly when you can cut and paste sections of working code. But before we get into the how-to, let’s go over the what.
A subroutine is a named section of code that gets run only when something in the script calls it by name. Nearly every script we’ve worked with thus far has been a group of commands, which have been processed from top to bottom in a consecutive fashion. Although this consecutive processing approach, which I call linear scripting, makes the code easy for the network administrator to work with, it does not always make his work very efficient. In addition, when you need to perform a similar activity from different parts of the script, using the inline cut-and-paste scripting approach quickly becomes inefficient and hard to understand. This is where subroutines come into play. A subroutine is not executed when its body is defined in the code; instead, it is executed only when it is called by name. If you define a subroutine, and use it only one time, you might make your script easier to read or easier to maintain, but you will not make the script shorter. If, however, you have something you want to do over and over, the subroutine does make the script shorter. The following summarizes uses for a subroutine in Microsoft Visual Basic, Scripting Edition (VBScript):
Prevents needless duplication of code
Makes code portable and reusable
Makes code easier to troubleshoot and debug
Makes code easier to read and maintain
Makes code easier to modify
The following script (LinearScript.vbs) illustrates the problem with linear scripting. In this script are three variables: a, b, and c. Each of these is assigned a value, and you need to determine equality. The script uses a series of If Then...Else statements to perform the evaluative work. As you can see, the code gets a little redundant by repeating the same statements several times.
Option Explicit Dim a Dim b Dim c a=1 b=2 c=3 If a = b Then WScript.Echo a & " and " & b & " are equal" Else WScript.Echo a & " and " & b & " are not equal" End If If b = c Then WScript.Echo b & " and " & c & " are equal" Else WScript.Echo b & " and " & c & " are not equal" End If If a + b = c Then WScript.Echo a+b & " and " & c & " are equal" Else WScript.Echo a+b & " and " & c & " are not equal" End If
OK, so the script might be a little redundant, although if you’re paid to write code by the line, this is a great script! Unfortunately, most network administrators are not paid by the line for the scripts they write. This being the case, clearly you need to come up with a better way to write code. (I am telegraphing the solution to you now...) That’s right! You will use a subroutine to perform the evaluation. The modified script uses a subroutine to perform the evaluation of the two numbers. This results in saving two lines of code for each evaluation performed. In this example, however, the power is not in saving a few lines of code—it’s in the fact that you use one section of code to perform the evaluation. Using one section makes the script easier to read and easier to write.
In the script you are currently examining, your business rules are contained in a single code section, so you can easily modify the code to incorporate new ways of comparing the three numbers (to determine, for example, that they are not equal instead of equal). If conditions are likely to change or additional information might be required, creating a subroutine makes sense.
Calling the Subroutine
In the next script you’ll examine, SubRoutineScript.vbs, the comparison of a, b, and c is done by using a subroutine called Compare. To use a subroutine, you simply place its name on a line by itself. Notice that you don’t need to declare the name of the subroutine because it isn’t a variable. So, the script works even though you specified Option Explicit and did not declare the name used for the subroutine. In fact, you cannot declare the name of your subroutine. If you do, you will get a “name redefined” error.
Creating the Subroutine
Once you decide to use a subroutine, the code for creating it is very light. Indeed, all that is required is the word Sub followed by the name you will assign to the subroutine. In the SubRoutineScript.vbs script, the subroutine is assigned the name Compare by the following line: Sub Compare. That’s all there is to it. You then write the code that performs the comparison and end the subroutine with the command End Sub. After you do all that, you have your subroutine.
Option Explicit Dim a, b, c Dim num1, num2 a=1 b=2 c=3 num1 = a num2 = b compare num1 = b num2 = c compare num1 = a + b num2 = c compare Sub Compare If num1 = num2 Then WScript.Echo (num1 & " and " & num2 & " are equal") Else WScript.Echo(num1 & " and " & num2 & " are not equal") End If End Sub