Scripting

Here are some of the "best practices" I like to adhere to (sometimes):

1) Make your code reusable through subs and functions.

2) Use spacing and indentation to make your scripts more readable - some people recommend comments, but I find that well written code is most often self-explanatory. If you're not a scripter just ask me what it does!

3) Use "Option explicit" and declare your variables even though you don't have to.

4) Pick some kind of variable naming convention, and stick to it. Your company may already have guidelines regarding this subject. There's nothing more annoying than one person using "Shell", another "oWsh", and another "WSH". It's nice if the variable name suggests the variable type, even if everything's a variant in VBScript. Capitalizing the first letter of each word looks good.

5) Declare your most commonly used objects outside your reusable "subs" and "functions" - in large scripts this avoids creating and destroying objects over and over again. This is the most important reason for sticking to a consistant naming convention.

6) Declare variables as constants unless they really are variables. I like my constants to be UPPERCASE so I recognise them.

7) Create a script template of your own with all your standard declarations.

8) Include some kind of error handling (I know I should practice what I preach)! At the very least, avoid scripts that crash with cryptic errors messages that lead the user to call the helpdesk with little or no information - "On Error Resume Next" can help you achieve this.

9) Make your script return the result of what it's done (or not done) in case someone might be interested - "Wscript.Quit(n)".

10) Include a script header detailing the author, the date, the purpose, the usage, etc. If it's a "living"/"evolving" script, it may be worth including a revision number or a "last modified" date.

11) Don't always blindly download someone else's code, or you'll never learn anything. Besides, there might be a better way of doing it!

12) Try not to hard-code anything!!! Like IP-adresses, paths, server names, etc. Pass these things to your script, and retrieve them using "Wscript.Arguments(n)".

There must be many more - but this should be a good start.

Thanks - I wasn't doing too bad but guilty of some definately, this is very helpful.

Question, can I do an "On Error Call Sub" or something to that effect?

No, but you could do something like this:

On Error Resume Next
Err.Clear : If Err.Number <> 0 Then MySub
On Error Goto 0

Sorry, that's garbage - I meant:

On Error Resume Next
Err.Clear
.
.
.
.
.
If Err.Number <> 0 Then MySub

The problem is I don't want it to resume the next line of code, ideally I want it to do Wscript.Quit(XX) with a number I specify.

So, if you check for the error where you expect it to occur and handle it at that point. Then, at the end of your script handle any unexpected errors:

On Error Resume Next
.
.
.
.
Err.Clear
Set oWsh = CreateObject(Wscript.Shell)
If Err.Number <> 0 Then Wscript.Quit(XX)
.
.
.
.
If Err.Number = 0 Then

Set oWsh = Nothing
Wscript.Quit(0)

Else

Msgbox "An unexpected error has occurred.", vbCritical, "Error"
Wscript.Quit(Err.Number)

End If

I don't know where any errors will occur, but basically I don't want it to continue any further than the line it failed on - and ideally I would like to put the error line in the Wscript.Quit.

If i've understood correctly to handle errors I need to make educated guesses on where they might occur?

Here's an example problem though...

Line 10 - install program X
Line 11 - install program Y that is dependent on program X
Line 12 - run program Z that needs program X and Y

In the above scenario if didn't know where it was going to fail - do I need to put an error handling line after each line?