1. Put all the configuration information at the beginning of the script. That way, you're editing only one section in the script, minimizing the chance of introducing errors.
2. If your script will write information to the same output file several times, use a variable to represent the file's path instead of hard-coding the file's path each time. This practice not only reduces the chance of specifying an incorrect path but also saves time. If you need to change the file's path, changing the path once is much quicker than having to search through all the code and replace the path in each spot it appears.
3. Make life easy on yourself, your coworkers, and whoever follows in your footsteps by including comments in your scripts. The code you write might make a lot of sense today, but tomorrow it might look like an unknown language. On more than one occasion, I've tried to figure out who wrote a script, only to discover it was a script I created a few years earlier.
The common way to comment Windows shell scripting code is to put either Rem or double colons (::) at the beginning of each comment line. Unlike some other scripting languages, Windows shell scripting doesn't let you put comments on the same line as the code. Put your comments in the lines preceding the code.
4. Consistently use intuitive variable names. For example, if you're using a variable that contains a user ID, name it UserID rather than Var1. Using intuitive variable names will make it easier for you to read a script and easier for your coworkers or successor to understand it. Using intuitive variable names will also make it easier for you to reuse the code in other scripts.
5. Put your tools in a common folder that has no spaces in its path. As you begin to write scripts, you'll quickly go beyond using internal Windows commands to using Microsoft utilities (e.g., resource kit tools, support tools) and third-party utilities. Hunting down the location of a utility you used previously can be frustrating.
Putting all your tools in a shared folder is best because you can then point to a central location in all your scripts. However, tools sold as licensed software might have restrictions on their deployment to multiple nodes. If you have such a tool, you first need to confirm that you have an appropriate site or multinode license.
Currently, Windows Support Tools and Windows resource kits are installed, by default, into an installation path that contains spaces. For scripting purposes, a path with spaces isn't recommended. When paths with spaces are embedded inside the commonly used For command, the spaces can cause cryptic errors that are difficult to diagnose. Be diligent and change the installation paths for all your utilities so those paths are free of spaces.
6. Always carefully test your scripts in a nonproduction environment before you run them in your production environment. If a script that simply creates reports or performs data queries isn't working properly, not too much fallout can happen beyond the script producing inaccurate reports or data. However, if a script that deletes files or modifies settings isn't working properly, the fallout can be devastating. Although you can incorrectly delete files or modify settings with a system's built-in tools, a poorly written and improperly tested script can do a lot of damage much faster. By carefully and thoroughly testing scripts in a nonproduction environment, you'll minimize risk of unintended changes in your production environment.
End of Article
Register
