Well, asking is a good sign that you are on the right track.

Some varied rambling thoughts...

Scan the FAQs for some guidelines on coding techniques and good practices. They are not hard and fast rules - some are personal preferences and some have evolved through discussion, but they make an excellent starting point.

If you find yourself using "GOTO" when you know that the modern pedantic coder considers it an anathema don't fret - you are learning and you will not know how to avoid it in some situations. When you post the code and are lambasted for such an appallling lack of coding grace you can ask how to code it differently, and you will learn something new

Get a piece of paper and sketch out your objectives. Start with the high level and get a loose definition of the process down. Use your artistic talents and produce a flow-chart.

Break down the high level process into tasks - keep the task descriptions very short.

Doing this beforehand will naturally lead you into laying out your program as a series of tasks, sections or modules. This will tend to encourage your code to be organised.

You may also see common or similar tasks appearing repeatedly in your process - these are opportunities for User Defined Functions.

Now you have an idea of what you want to do, you should be able to look at the processes and make sure that you know what you need for each task - gather together information about server names, directory paths, WMI or ADSI objects, the format of data files or user input and so-on.

Once you have that all together, you might as well getting something in your script file. Rough out the script by putting in comment sections that mirror your tasks, and define all your User Defined Functions - the actual code will come later.

At the top of every script you start, include the following lines:
Code:
Break ON
$=SetOption("Explicit","ON")
$=SetOption("ASCII","ON")
$=SetOption("WrapAtEOL","ON)


You may want to take out the BREAK ON when the code goes into production, but leave it in while developing.

You should also try to avoid using variables within strings and set the option:

Code:
$=SetOption("NoVarsInStrings","ON")


DIM all your variables near the top of your script, and avoid GLOBAL variables. GLOBAL variables are useful for static (constant) information and to maintain stateful information for UDFs, but are rarely needed and will cause you trouble if you rely on them.

Give your variables meaningful names - there are good recommendations for a protocol called "short form hungarian notation" in the FAQs.

Indent your code. It is not vital that you choose tabs or spaces, but be consistant in both the characters and the number that you use for each level of indentation. When you add or remove code, take time to go back and fix the indentation if it has changed - you will find that this alone will trap many of the common errors like IF without ENDIF.

Work on each of the tasks in your script one at a time where possible - don't try to write the entire script at the same time. Once you are happy that the section is clean, accurate and as good as it is going to get you can move on to the next.

When you come to complex tasks, write down the detail on paper in pseudo-code. This is just a simple English description of the process which you can translate directly into script once you have a better idea how it is going to work.

If you have any really complex code that you think will take a few attempts to get right, take just the complex process and work on it in a temporary script. When you have worked it out and are happy, transfer it into your main script.

The most important thing is to have a clear idea of the layout of the script before you begin. Once you are experienced you will do this in your head for simpler scripts, but while you are learning get it on paper first.