GPMS Source Code Style Guide.

1. Functions will be fully prototyped.  Functions that return int will
explicitly be prototyped as such; functions that take void as a parameter
will be explicitly prototyped as such.  Function parameters will be fully
declared in the function list.  In other words, K&R 1st Edition function
declarations are not valid - use K&R 2nd Edition as a model.  Prototypes
may include parameter names, or simply parameter types - this is left to
the programmer.  If parameter names are used in the prototype, they must
match the names used in the actual function.

Declarations:

bad:  somefunc()
good: int somefunc(void)

bad:  int somefunc(a,b,c)
      int a, b, c;
good: int somefunc(int a, int b, int c)

------

Prototypes/declarations:

bad:  int somefunc(int a, int b, int c);
      ...
      int somefunc(int var1, int var2, int var3)

good: int somefunc(int a, int b, int c);
      ...
      int somefunc(int a, int b, int c)

good: int somefunc(int, int, int);
      ...
      int somefunc(int a, int b, int c)

------


2. Braces enclosing a function will be aligned on the far left margin.

Bad:

int somefunc(void)
    {
    ...
    }

Good:

int somefunc(void)
{
  ...
}


3. Each level of indentation will be two spaces.

4. Blocks of code enclosed in braces will have the starting brace on the
same line as the if, for, while, switch, do, etc, or on the line immediately
below the statement (depending upon context and personal preference).  The
enclosed code will be indented, and the ending brace will align with the
starting statement.

Bad:

while (1)
  {
  ...
  }

while(1) {
  ...
  }

Good:

while(1) {
  ...
}

while(1)
{
  ...
}


5. #defines, #includes, function prototypes, global externs, and global
statics appearing outside any function will be aligned on the far left margin.

6.  Comments are to be used liberally.  The programmer may choose to use
either C-style or C++ -style comments.

7.  Function and variable names are left to the programmer (ie, no standard
use of Hungarian or other naming conventions).  Function and variable
names, however, should be illustrative of the objects' purpose.

8.  The following constructs are permitted to save screen space.  They
should be used sparingly, and only when they make sense in a particular context.

if (test) somefunction();
if (test) { somefunction1(); somefunction2(); }
if (test)
  { somefunction1(); somefunction2(); somefunction3(); }

9. An 80-column line should be assumed.  Lines should not extend past 80
columns, except when the object is a string or a very long function or
variable name.  Newlines should be used to break long function parameter
lists into smaller chunks.

10.  Use of extra parantheses is left to the programmer.

 good: if ((i == 1) || (i == 2)) ...
 good: if (i == 1 || i == 2) ...

11.  All new code is to be written to these standards.  Old code will be
modified to match these standards whenever possible, and as it is modified
for other reasons (ie, no mass code-revision project).


SJJM
05/15/1997