Expanding Scope for Your Scripts

A wise programmer once said, "If it weren't for 'expanding' scope, there probably wouldn't be any scope at all." This statement is especially true in the scripting world. Typically, a client provides some initial requirements, which you use to write a script to perform task A. A few days later, the client, who's happy with the results of the first request, asks you to expand the scope of the requirements to include task B and often tasks C, D, and E. Expanding scope is usually good news because it means job security.

One potential downside of expanding scope is that if you focus only on the client's current need and the task that the client wants performed at the moment, you might delete or overwrite earlier versions of a script that performed other valuable tasks and could meet a client's requirements in the future. I try to use the Save As command frequently when I save my script versions so that I won't lose good working code that's potentially reusable. Leveraging your script development time by saving all code you write and reapplying it to new situations can help you quickly respond to new requirements.

To help you decide when it's advantageous to merge scripts, you need to make two determinations. First, you need to determine whether it makes sense to combine tasks from multiple scripts. If the scripts' tasks are vastly dissimilar, combining them probably isn't a good idea. Second, you need to determine whether the scripts' code is similar enough to let you combine the scripts.

After you've decided to merge two scripts, you need to combine the code. Here are some tips to help you:

Check the old scripts for duplicate label names. If the label names aren't unique, the flow might erratically jump between sections, thereby producing unintended results. For example, I used two different scripts to create GetNodePingStatus. When I combined those scripts, I had to change the FindLoc and Begin labels in the incrementing section to FindLocni and Beginni in the nonincrementing section to avoid the use of duplicate label names.

Check the old scripts for duplicate output-file names. If the taskrelated sections each produce an output file, be sure that you give each output file a different name. For example, in GetNodePingStatus, I used output.csv for the output file produced by the incrementing section and noincoutput.csv for the output file produced by the nonincrementing section. I didn't want to launch GetNodePingStatus in incremental mode and have it overwrite the output file that's created when the script is run in nonincremental mode.

If the scripts perform distinct but related tasks, you can use command- line switches in conjunction with an If command at the beginning of the script to route script flow to the appropriate section. Take, for example, the following code in GetNodePingStatus:

If /I "%1"=="-inc" Goto :Inc
Goto :NoInc

If the person launching GetNodePingStatus specifies the -inc switch, the If command sends the script flow to the incrementing section. Otherwise, the script flow goes to the nonincrementing section.

If the two old scripts have code in common, you can place this code at the beginning of the combined script. That way, you have to use the common code only once because it precedes any code that might route the script flow to the unique task-related sections. For example, in GetNodePingStatus, I placed the date and timestamp code prior to the code that sends the script flow to either the incrementing or nonincrementing section.