Introduction
------------
This is part 1 of the style guide.  It concerns how the C/C++ syntax 
should be formated within a file.

Unified coding style is important because it eases software review 
and maintenance.  This file specifies guidelines which can be broken 
for specific cases, but should be adhered to as closely as possible.

Plastimatch can't be properly formatted automatically by GNU indent 
or astyle.  Uncrustify will do a decent job; an uncrustify configuration 
file is included in the distribution.

Files
-----
Source code files should use Unix-style end-of-line characters.
All source code should be written in 7-bit clean ASCII.

Third-party code
----------------
Third-party code should be placed in separate files, and should be 
clearly identified, so that no mistake in licensing occurs.

Indentation
-----------
Indentation should be 4 spaces.  Tabs are allowed, but you must set 
your tab stop to 8 spaces.  Note that this is not the default 
for Microsoft Visual Studio compilers, so you should adjust your setting.

Line breaking
-------------
Code should be limited to 80 columns when possible.  Use typedefs to 
assist in this process.

Curly braces
------------
Use GNU curly brace style (curly on its own line) for function 
definitions, and K&R curly brace style (curly on same line as conditional)
everywhere else.

Always use curly braces for if/do/while/for statements, even if there 
is only one statement in the block.

For a simple else clause, cozy it up with the previous right curly.  
For testing multiple cases, move the else keyword to a new line.

Examples:

    int
    foo (int bar)
    {
        if (bar == 3) {
            return 1;
        } else {
            return 0;
        }
    }

    int
    foo (int bar)
    {
        if (bar == 3) {
            return 1;
        }
        else if (bar == 5) {
            return 2;
        }
	else {
            return 0;
	}
    }

Switch statement
----------------
Case labels are not indented in the switch statement.  A default label 
is required (even if there is no code).

    switch (x) {
    case a:
        code;
    case b:
        code;
    case c:
    default:
        code;
    }

Function definitions
--------------------
Declaritors and return values go on a separate line (GNU style):

    static int
    foo (int bar)
    {

Use explicit "void" in the argument list if there are no arguments
is optional:

    void
    foo (void)
    {

Horizontal whitespace
---------------------
Horizontal whitespace is used between operators and operands.  
Conditionals should be laid out like this:

    if (bar == 3 && baz > 4) {

Function calls like this:

    foo (a, b);

When there are no arguments, you may omit the space:

    foo();

Pointers and references
-----------------------
As per linux kernel style, put the '*' adjacent to the data name or 
function name and not adjacent to the type name.

    char *foo;
    char *bar (char *baz, char **boo);

The reason for this rule is it allows the declaration of multiple 
variables of the same type in a sinIntroduction
------------
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 and one cxx file.  
These pair of files will normally define a single public
C++ class, and optionally will define a second private C++ class.

The public class name will have the same name as the h and cxx file. 
For example, the class Plm_image is defined in plm_image.h.

The private class will include the suffix "_private", and is defined 
in the cxx file.  For example, class Plm_imag