3.4 Naming Conventions and Variables
By convention, all local function names (as opposed to library calls)
begin with Do ... DoListSkills ,
DoFindTarget etc. This makes it easier to recognize which
functions are defined in the file you're working on, and often makes it
easier to find functions within the file (for example, searching the file
for a list function will get fewer false hits when the function is named
DoList rather than List ). Now, one would think
that this means that all library calls don't begin with
Do ... unfortunately, a few Do 's did creep
into lib-argo: DoEnable , DoDisable , and
DoVersion . These three library functions always appear in
contexts where a name without the Do prefix would mess up
the pretty columns in the code. This was simply unbearable.
All function names, in the library and the local programs, begin with
upper case.
Except for the frequently used workspace variable
scratch , all local variable names begin with
our ... ourPlayer , ourString ,
etc. All variable names begin with lower case.
Whenever possible, all command #options begin with a
different letter. This allows users to specify an option by typing only
one or a few characters of the option string... #search ,
#sea , and #s would all invoke the
#search option. The only exception made to this in the
standard Argo programs is with commands such as
+check and +combat , which have an
#on and #off option... instances where (1)
it's not hard to type the whole thing, and (2) nothing dramatically
wrong will happen if the user specifies an option with just
#o . Following this convention in new Argo programs
is strongly encouraged.
Variables
You can of course declare your own variables as needed. All
Argo programs declare a standard set of variables. Those which
can be reliably initialized at the beginning of a process are
initialized, as discussed below:
ourArg
This variable holds the command argument. In the (relatively rare) cases
where the arguments to an Argo command can include both an
#option string and an additional argument beyond this,
ourArg will contain only the additional argument, and
ourOption will contain only the #option
string. ourArg is initialized early in the
main function in all the skeleton programs.
ourBoolean
This variable is used for quick and dirty flow control in the standard
Argo programs. Feel free to use it in the same way in your own
programs. ourBoolean is not automatically initialized.
ourCom
The ourCom variable contains the `official' Argo
name of the current command, regardless of whether it has been renamed
or aliased. For example, in asys-background, ourCom
always contains the string "+background" , even if the
command has been renamed or aliased with names such as +bg
or background . Use ourCom when you need the
official name for display purposes, and the built-in
command variable when you need the command name the user
actually typed. ourCom is initialized early in the
main function in all the skeleton programs.
ourCounter
This is a generic counter variable, for loop control and the like. It is
not automatically initialized.
ourDataObj
The ourDataObj holds the dbref of the object holding the
data that defines the current realm... the realm environment room, in
other words. It is initialized early in the main function
in all the skeleton programs.
ourOption
The ourOption variable contains the #option
string a user typed with the command name, such as #search .
For programs that can take #options followed by additional
arguments, ourOption will contain only the
#option , and the remainder of the command line argument
will be stored in ourArg . For programs that take
either an #option or a regular argument,
both will contain the entire argument string... you can use either, in
other words. The standard programs use ourArg in these
cases. ourOption is initialized early in the
main function of all the skeleton programs.
scratch
A miscellaneous workspace variable. It is not automatically
initialized.
prev |
toc |
top |
next
|