Module programming guidelines: Difference between revisions

already been used.  Perhaps this will evolve over time and become  

more formalized and/or automated.  After obtaining a unique module  

having global scope as outlined below.

; Uppercase Notation : all uppercase characters, underscore

; Lowercase Notation : all lowercase characters, underscore

characters to get optimal use of the Script Editor's auto-complete  

feature.  More than 16 characters makes using the module overly  

<pre>

Enumerated data types are defined in the Module Header and have  

global scope.  { At the time of this writing, it is not clear to the  

Script have }  The enumerated types name is formed using Camel  

Notation prefixed by the module name.  The enum value names are  

speaking functions can be local or global in scope.  However, AGS  

does not permit forward references, so in practice local functions  

application function.  The intent of these groupings is to organize  

the Module Script so that forward reference problems do not arise.   

Instances of structures are to be named according to the above rules  

governing the naming of static and dynamic variables. Instances of  

and so are static and are named using Camel Notation.   

Normally there will be a "main" structure, defined in the Module  

name is, of course, in Camel Notation as is the module name.  The  

names of public members are to be in Camel Notation while the names  

The distinction between public and private members is that public  

only by other members of the structure.

</pre>

functions as it is more consistent with the new AGS scripting  

language.  As of this writing, static member variables are not  

First of all, modules should be as self-contained and independent as  

module to use functions defined in an other module.  Such a module is  

said to be dependent on the other module.   

For example, suppose someone is creating a module that will need to  

do extensive database operations to achieve it's purpose.  If a  

better to just use that module rather than replicating the required  

database functionality.  On the other hand, if only a small portion  

If a module is dependent on another module and that module hasn't  

will be generated.  It will not necessarily be obvious why these  

specific version of a module.  So a method of explicitly checking for  

required. This can be done by defining and checking macro definitions  

in the Module Header as described below.

Each module is also required to have one macro definition named  

ModuleName_VERSION defined as the current version number.  Each  

released version of the module, named ModuleName_VERSION_XXX, where  

XXX is the release version number. An example of this is shown below.

</pre>

extracting comments from the Module Script and Module Header and  

include the following sections.  {note such a document generator is  

=== Create Distribution File ===

files are compressed into a single zip archive for distribution.  

module to be redistributed by others (i.e. mirrored on other  

websites).  To use the LGPL just include the following notice in the  

    

<pre>