prev | toc | next
 

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