FUN WITH COMMENTS
Many people understand the theoretical basis for using COMMENTs within ACL scripts. COMMENTs serve as the foundation documenting scripts. A well written script will be properly documented both internally and externally. While I will probably write essays on the proper way to document scripts, that is not what this essay is all about. This essay is about actually using COMMENTS as a script writing tool.
When I write scripts I use comments as part of my developmental process. This is particularly true when working on a project that is an on going program. For example, I may have a project in production that is being used on a regular basis and another project that I am working on in development. The project in production is a version that I know works and will have a specific path for both the data and the output. The project in development is the one where I am attempting to enhance the version in production and will have a different path for the data and the output.
One way to write the code would be to manually change the path depending on whether or not the script is in development or production. Unfortunately, this method poses a lot of risk. What happens if the programmer fails to make the correct changes? What happens if the programmer misses one of the many changes necessary to go from production to development or vice versa.
Using comments and variables, one can overcome this issue.
In the master script, I might have a section of codes that looks like the following:
COM*********************************************************
COM The following variables should COM'd out if the script is in production.
COM*********************************************************
v_dev = "COM "
v_prod = ""
COM*********************************************************
COM The following variables should COM'd out if the script is in development.
COM*********************************************************
COM v_dev = ""
COM v_prod = "COM"
The above would set the variables v_dev and v_prod for the version in development. I might then have variables "v_path_data" and "v_path_results" that I use to define the data path for the data and the results.
%v_dev% v_path_data = "C:\ACL\developement path\"
%v_prod% v_path_data = "C:\ACL\production path\"
%v_dev% v_path_results= "C:\ACL\developement path\results\"
%v_prod% v_path_results= "C:\ACL\production path\results\"
As there might be other cases where there are differences between the production version and the developmental version, by using the variables v_dev and v_prod, I can ensure that the developer only has to make one change when moving the results from development to active scripts.
This concept can be used in other areas of script writing as well. You might have some parameters that you want to set for projects dealing with one business unit and not another, this might be a way to COMMENT out those parameters.