ContentsNaming Variables
You can name your variables almost anything you like, but there are a few rules and guidelines you should follow:
Variable
names can only contain letters, digits and underscores.
Variable names can be made up of any combination of letters, digits
and underscores as long as they do not begin with a number and do not
conflict with any reserved
keywords.
Variable
names are case sensitive.
The names MyVar and myvar
each refer to a different variable.
Don't
use any hyphens (-) in your variable names.
The hyphen is used as an operator
in AutoPlay. If you put an operator in a variable name, it will "break
up" the variable into two separate variables, resulting in a syntax
error (if you're lucky) or some kind of unexpected behaviour at run time.
For example, Foo-Bar would be seen as subtracting the value of "Bar"
from the value of "Foo" using the "-" operator.
Try
to use meaningful names.
For example, if you read a product's installation date from the Registry,
naming the variable Greegleborg452sx probably isn't a good idea. Use a
variable name like InstallDate instead.
Use
prefixes to your advantage.
A common tactic among programmers is to use short prefixes like "str"
and "n" to mark variables according to what kind of data they
contain—such
as string or numeric values. Although AutoPlay's variables can hold any
type of value at any time, it can still be helpful to use prefixes in
your variable names. For example, using this system the name strResult
would be used to contain a string, and the name nResult would be used
to store a number. Prefixes help make your intentions clear in such cases
where the name is somewhat ambiguous on its own.
Be
consistent.
If you start out with UserName and UserAge, don't name your third variable WhereTheUserGoesToWork.
A name like UserCompany will be easier to
remember when you find yourself asking "what did I name that variable,
again?"
Don't
use any of the action category names.
Action names are made up of a category, like Application or File, followed
by a dot and a function name, like Exit or Copy. For example, the Application.Exit
action is located in the "Application" category, and the File.Copy
action is located in the "File" category.
Using a variable name like "Application" or "File"
will cause all of the actions in that category to be inaccessible. This
is because the action names are implemented as tables containing functions.
For example, the File category is internally represented by a table containing
the various file functions like Copy, Find, and Open.
Since assigning a value to a variable overwrites any value that is
already in the variable, assigning a value to a variable named "File"
will replace the File category with your value.
So, as a general rule, never name your variables anything that appears
to the left of a period in an action name.
Don't
assign a value to a built-in variable by mistake.
For example, assigning a value to a variable called _SystemFolder
would override the built-in variable with the same name. Take time to
familiarize yourself with the list of built-in global
variables so you don't use any of them by accident.
Don't
use the same variable name twice unless you mean to.
Using a name twice is fine if you're assigning a value to a variable
in one place, and accessing that value in another. Just be careful not
to unintentionally give the same name to two variables if they're being
used to represent two different things.
Of course, it's okay to assign a value to a variable twice if you want
its value to change. In that case, the first value will only be in effect
until the second one "overwrites" it.
Avoid
using accented characters in variable names.
We recommend avoiding variable names with accented characters.
Some characters have been known to cause issues.
When
in doubt, double-check.
A common mistake is to name a variable one thing in one part of your
project, and start calling it something else later. If you're not sure
what name you used, double-check by going back to the place where you
defined the variable.