| 1. |
Debugging Recommendation:
Watch for an initialization of a variable with an extra space.
For example: SET VAR=value▌.
If the ▌ character is the space, it is used in the value of the field and can be difficult to debug. Use the end key in the editor to move the cursor to the end of the line to visualize the space. The extra space can also be at the beginning of the string. |
| 2. |
Insert a debugging breakpoint into a program with an ECHO and PAUSE statement. |
| 3. |
Turn on tracing by setting the ECHO ON statement. |
| 4. |
A small script (1 to 2 pages) will be easy to trace through and understand the program logic. However, large .BATs and multiple .BATs can be difficult to work
with.
An important aid for reviewing code, documentation and debugging is a cross reference list. .BATs scripts do not provide a cross reference report; however,
C#, Perl, Access, VB or any language with character manipulation can be used to code one. The system will read all the BATs, extract symbolic variables, program names, token location, CALL routine locations and initialization
statements. The results can be sorted and a cross reference displayed and printed.
Reports that can be produced include:
| Variable Cross Reference |
Call Routines Usage |
Variable
Initialization Locations |
| Dataset Locations |
Program Execution Locations |
ERRORLEVEL Values
|
|
| 5. |
Create a logfile to indicate the steps processed and error conditions. |
| 6. |
SETLOCAL and ENDLOCAL need to be used carefully. |
| 7. |
Always check ERRORLEVEL after every CALL and program execution. |
| 8. |
Before using a file, check if it exists. |
| 9. |
Be vigilant in looking for comparison and case sensitive strings. |
| 10. |
Watch out for utilities that ignore case (i.e. Windows SORT). |
| 11. |
There are some programmers that will capitalize all labels and keywords (if, for, exist etc). Most .BAT programmers do not utilize indentation; therefore, making it difficult to maintain the code. Indention makes the code more readable. |
| 12. |
Standards should be developed for coding comments, change logs and system flow documentation. |
| 13. |
In IF statements comparisons, delimit the comparison string with a character such as “ or {. |
| 14. |
Use environment variables as quick scratch variables as much as possible. This should always be preferred to hard-coding values because it's easier to change an environment variable
reference in one place than it is to do a find and replace operation. This also keeps the code more readable. |
| 15. |
Always make @echo off the first line of finished batch files. Normally, the user of the batch will not want to know what's going on while a program is executing. |
| 16. |
Initialize all temporary variables at the beginning of the batch file and clear them at the end.
:Start
set _foo=0
set _bar=temp.dat
:end
set _foo=
set _bar=
|
| 17. |
Prefix temporary batch-specific variables with an underscore character to avoid name clashes. This practice can be extended to temporary text files that are created by batch files as well. |
| 18 |
Take full advantage of variables specified on the command-line and prefer that approach to asking stuff interactively whenever you can. This is handy in unattended
batch sessions and when batch files call each other. |
| 19. |
Do not use terse cryptic comments inside the file; rather document the batch in a text file with the same basename when related documents are necessary.
For example, mybat.bat should have documentation in mybat.doc. |
| 20. |
When identical commands are used repeatedly used in a file, it is a good practice to move that code into another batch file and then call the
code into the main file. |
| 21. |
Instead of placing parameters in a global variable that multiple batches will have access to, pass parameters to batch files as command-line parameters, |
| 22. |
When placing multiple statements after the if, else or do clauses, indent the commands in parenthesis with a fixed number of spaces; the recommended practice is to use three spaces. Do not use tabs; the size of the indentation will vary based upon the text editor being used. |
| 23. |
For commonly used batch files which are accessed frequently, create a directory such as c:\bats\ and place it in the path in order that all the batch files will be available from any directory. |
| 24. |
If there is a requirement to distribute batch files, ensure that there is sufficient error checking. |
| 25. |
Normal batch files, will need to contain the finish and cleanup label segments. This is necessary to ensure that the variables will be set and cleaned up when their
use is over. This framework will facilitate searching for the sections in a large bat file. |
| 26. |
The recommended practice is to use "SetupEnv.bat" for setting up the global variables and ending the batch file execution by calling "CleanupEnv.bat". If they do not already exist,
both files will need to be created. This will serve to limit the changes that occur to the global variables to a single file; this will facilitate any future editing. |
| 27. |
All batch file names should start with a capital letter followed by small letters; each word thereafter should then be capitalized. |
