If you've been writing scripts for a while, you're probably beginning to realize that you're writing less new code and are more frequently reusing blocks of code from existing scripts. You might reorganize the code or use it with different utilities, but you're likely to find that almost 80 percent of the code you use in new scripts consists of modules that you originally wrote for earlier scripts.
Reusing code has huge benefits. When you have a piece of code that you know works, why rewrite it? Reusing well-written code modules lets you more easily follow the script flow and logic, debug the code when problems arise, and leverage your code to quickly create new scripts.
One big problem in trying to assemble code modules into a new script is a lack of consistency in environment variables. In shell scripting, environment variables are the exchange mechanism for passing values between code modules and outputting script results to the console and to log files. Unless you're much more organized than I am, you've probably created different variables in your scripts that describe similar items. For example, I looked over a few of my scripts and discovered that to describe computer names, I've used variables named PC, PCs, node, comp, srvr, srv, srvname, server, and servername. When you reuse modules that you know work but that have inconsistent variables, you'll need to spend time debugging your new script, reconciling the inconsistencies introduced in various modules, and doing global replacements before your new script will work properly.
By standardizing your variables, you can greatly reduce the debugging you need to do for new scripts. Consistent, succinct, and intuitive variable names will also save you time when you're assembling code and make your scripts more readable. As an aid to standardizing variables, Web Table A (http://www.winnetmag.com /windowsscripting, InstantDoc ID 41200) lists the variable names I use for commonly used items.
