Learning a new language you will find yourself scraping the net looking for any number of resources that will aid you in writing good code, but one of the frustrations I found was that Microsoft Scripting is not particularly consistent in their code management. There are any number of other forums that will give you band aid solitions for the "How do I..." code. However it gets very tempting to copy and paste from these sites without actually working out what you have done.
So todays lesson will be on two words. The first two words you should write in a vbScript without a comment in front of them.
Option Explicit
What does this do? It forces you to declare variables, it forces you to think about whether the routine you are writing is a Subroutine or a Function. In short, it forces you to stop writing spaghetticode and start thinking about what you are writing.
When faced with a new peice of code that needs to be written, my first step will be to write it out something like this
Option Explicit
' What do we want to do here?
' Open an ini file and check that it contains all the info we want
' grab the latest data from central server
' copy this data out using patching routines
' log all of the above
All of these steps break down quite nicely later on. I only have to fill in the blanks now with useful code. But now I can start using the limitations placed on me by Option Explicit to think about variable names.
At the moment I am coding a fancy "Copy Files" routine that should automate periodic data upgrades once out of testing. I found that this needed a tie in from four scripts to do the job. One to set up the "Golden Source", one to control how many servers to replicate to at a given time. (I'm lucky the system I work on tends to have more servers on it than a lot of organisations have workstations.). One to do the actual copying, and one to launch the product on a workstation at the end of it all. 4 scripts written by 4 people. Each with their own idea about how it should go.
My boss (Who incidentally wrote and maintained the scripts before me) told me that looking after this should be my job. Great. I open each one up and see the pain before me. Spaghetti code and undelcared variables everywhere. Job One to work out this mess? Our favorite friend, Option Explicit. Running the script now errors horribly, but starts to produce a list of undeclared variables and the scope they cover off on. I now have a list of variables and have tidied up some of the subroutines.
What I find is that accross all four scripts are variables that contain the same information, but are called three or four different names. So as part of the rewrite, all global variables are renamed the same thing so it is easy to flick from script to script and see where the information is going and what it is being used for.
The other thing that it does is allows me to reduce memory footprint. Not particularly important to me as I am working on servers and power workstations where any less than 4GB of memory is considered obsolete. But as I go hunting through the subroutines I meet up with some friends.
- objFSO
- objFS
- objFileSys
- filesys
- fs
All prefixing
= CreateObject("Scripting.FileSystemObject")
Hmm. So what would happen if we have one name right through one script called one thing. We would be able to borrow this File System Object any time we want to do file operations. It's a handy class by the way. Does cool stuff. Not nessecarily predictably, but more on that in another rant.
So, because of Option Explcit, accross my four scripts, I only have to open the class once. Less of a memory footprint, and therefore more space for servers to do important stuff, like cope with an SQL call to push out a report to an executive.
Next time? why not have a look at things For a While Until we are Done.
No comments:
Post a Comment