|
-
Feb 6th, 2007, 03:33 AM
#1
Thread Starter
Addicted Member
A question of style: .vbs (NOT .asp)
I've been tasked to write a .vbs file to scan a local directory and ftp files to various locations.
I've been handed a few files which do roughly the same thing on which to base my script.
Now, the code I've been given makes repeated calls to an ini file to determine path settings etc. When it reads the ini file it reads the whole lot into a variable and then does a series of instr() to find the section it's looking for.
If I was developing this from scratch I would have loaded all this information into a handful of global variables at the start as I always feel repeated file reading like this is an unnecessary overhead.
Obviously having dozens of large variables loaded would be undesirable but at what point does it become better to read the settings as required rather than pre-load all the info?
Another light-hearted post from Guru 
-
Feb 6th, 2007, 09:19 AM
#2
New Member
Re: A question of style: .vbs (NOT .asp)
Everyone I have had this discussion with has a different take on it. The way I look at it is this.
How many variables are there.
(I prefer to set them as needed with the section of code that uses it
so that I can debug it easier later. Or if there are several, over 10 for a
script, I will try to defign them at the head of the script and comment their
usage in the script.)
How often do they need to be used?
(If they are accessed often in a short period of time then pre-loading them would
lower the execution time the script)
Are there any memory constraints on the pc/server that the script will be used?
(If memory usage is a concern then reading them as needed, assuming the variable
is removed from memory after it's use, can reduce memory requirements.)
I generally go for the option that leads to the shortest run time.
Just an opinion though...
SparkByte
-
Feb 6th, 2007, 06:05 PM
#3
PowerPoster
Re: A question of style: .vbs (NOT .asp)
Put them in the code, unless you require end users to edit settings and do not want them to mess up the code.
Optionally you could use seperate Include Files and read Subs or Functions from there.
Example:
Include File: Sub.inc
Add Procedures, Constants, etc
Code:
Const IncVar = 123
Sub DoSomething()
Dim cnt
Do Until cnt = 10
cnt = cnt + 1
Loop
MsgBox cnt
End Sub
Another Include File: Vars.abcdefg
with arrays
Code:
Dim varArr()
Redim VarArr(5,1)
varArr(0,0) = "Array 0,0"
varArr(0,1) = "Array 0,1"
varArr(1,0) = "Array 1,0"
varArr(1,1) = "Array 1,1"
varArr(2,0) = "Array 2,0"
varArr(2,1) = "Array 2,1"
varArr(3,0) = "Array 3,0"
varArr(3,1) = "Array 3,1"
varArr(4,0) = "Array 4,0"
varArr(4,1) = "Array 4,1"
varArr(5,0) = "Array 5,0"
varArr(5,1) = "Array 5,1"
Main Script:
Code:
Option Explicit
Call Main()
Sub Main()
On Error Resume Next
GetInclude("sub.inc")
If Err = 0 Then
MsgBox(IncVar)
Call DoSomething()
Else
MsgBox "Sub.inc Error!"
End If
On Error Goto 0
On Error Resume Next
GetInclude("vars.abcdefg")
If Err = 0 Then
Dim i
For i = LBound(varArr) To UBound(varArr)
MsgBox(varArr(i,0) & " - " & varArr(i,1))
Next
Else
MsgBox "Vars.abcdefg Error!"
End If
End Sub
Sub GetInclude(ByVal pFile)
Const ForReading = 1
Dim objFso, objFs
Dim sPath, sFile
Dim sCode
On Error Resume Next
sPath = CreateObject("Scripting.FileSystemObject")._
GetParentFolderName(Wscript.ScriptFullName)
sFile = sPath & "\" & pFile
set objFso = CreateObject("Scripting.FileSystemObject")
If objFso.FileExists(sFile) = True Then
set objFs = objFso.OpenTextFile(sFile,ForReading)
sCode = objFs.ReadAll
set objFs = Nothing
End if
set objFso = Nothing
If Err = 0 Then
ExecuteGlobal(sCode)
End If
End Sub
Last edited by rory; Feb 6th, 2007 at 07:10 PM.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|