Introduction
------------
This is part 2 of the style guide.  It concerns how variables 
and functions should be named to maintain a uniform look and feel.

Include files
-------------
Include files should be in the following order:

 1) plm_config.h
 2) Standard C++ include files (sorted alphabetically)
 3) Standard C include files (sorted alphabetically)
 4) Third party library include files (grouped, sorted alphabetically within	
    each group if possible)
 5) Plastimatch include files (sorted alphabetically)

File names and function names
-----------------------------
Generally, files will come in pairs, one H file for each C/CXX file.  

Global functions within a C file are usually prefixed by the 
name of the file.  For example, if a file is proj_image.c, then 
it should have functions such as proj_image_load () and 
proj_image_free ().

The class name within a CXX file has the same name as the file.  
For example, if the file is named Plm_image.cxx, the class is named 
Plm_image.

Function names: Object-oriented C
---------------------------------
When appropriate, C language files can use an object oriented style.  
Function names should use the following pattern.

    /* For objects created on the heap */
    Proj_image *proj;
    proj = proj_image_create ();
    ...
    proj_image_destroy (proj);


    /* For objects created on the stack */
    Proj_image proj;
    proj_image_init (&proj);
    ...
    proj_image_free (&proj)


    /* For objects created on heap by loading from file */
    Proj_image *proj;
    proj = proj_image_load (0, filename);
    ...
    proj_image_save (proj, filename);
    proj_image_destroy (proj);


    /* For objects created on stack by loading from file */
    Proj_image proj;
    proj_image_load (&proj, filename);
    ...
    proj_image_save (&proj, filename);
    proj_image_free (&proj);

Native layer, itk layer, wrapper layer [Proposed, not implemented]
------------------------------------------------------------------
The following prefixes should be used for these three layers:

  itk_xxxx            ## ITK layer, makes itk function calls.
  xxxx                ## Native layer
  plm_xxxx            ## Wrapper layer

Alternatives:

  plc_xxx             ## Native layer
  plm_core_xxx        ## Native layer
  plw_xxx             ## Wrapper layer

For images, we currently use this following:

  itk_image, itk      ## ITK layer
  volume              ## Native layer
  plm_image, pli      ## Wrapper layer

For complex images (multiple irregular spacings), consider the following:

  itk_volume, itk      ## ITK layer
  volume               ## Native layer
  plm_volume, plv      ## Wrapper layer

  plm_volset, plv      ## Wrapper layer (wrapper layer sufficient?)

The image header would become:

  itk_volume_header    ## ITK layer
  volume_header        ## Native layer
  plm_volume_header    ## Wrapper layer

  plm_volset_header    ## Wrapper layer (wrapper layer sufficient?)

Command line args, Function options [Proposed, not implemented]
---------------------------------------------------------------
Command line arguments are digested, and then placed in a structure 
called Xxx_args.  Example:

class Warp_args {
    ...
};

Complicated functions which are controlled by a structure full of 
options will use a structure called Xxx_opts.  Example:

typedef struct bspline_opts Bspline_opts;
struct bspline_opts {
    ...
};

N.b. The old way is to use the term "parms" for both types of structures.  

N.b. Does this even make sense?  Cxt_to_mha can use the same structure 
for both uses.

Dim, dims, offset, origin, spacing [implemented]
------------------------------------------------
To describe the position of an image in mm, use origin, not offset.  
The term offset is used to describe an ROI in voxels.

To describe the resolution of an image in voxels, use dim, not dims.

The order of parameters should be alphabetic:

  calling_a_function (dim, origin, spacing);

Except that direction_cosines is last:

  calling_a_function (dim, origin, spacing, direction_cosines);

For itk routines, it should follow the same semantic order, 
but it becomes non-alphabetic:

  calling_a_function (region, origin, spacing, direction_cosines);

Variable naming for indexing  [Proposed, not implemented]
---------------------------------------------------------
Fixed image voxel                   (f[3]), fidx <currently (fi,fj,fk),fv>
Moving image voxel                  (m[3]), midx < ditto >
    - what about ROI's              ?
    - what about physical coords    ?
Tile (fixed)                        (t[3]), tidx <currently p[3]>
Offset within tile (fixed)          (o[3]), oidx <currently q[3]>
Control point                       (c[3]), cidx <currently (i,j,k), m>
Coefficient array                   ?                <currently cidx>
Multiplier LUT                      qidx
Index LUT                           pidx
