Formatting standards:

It is important put the open-brace that starts the body of a C function
in column zero, and avoid putting any other open-brace or open-parenthesis
or open-bracket in column zero.  Several tools look for
open-braces in column zero to find the beginnings of C functions.
These tools will not work on code not formatted that way.

It is also important for function definitions to start the name
of the function in column zero.  `ctags' or `etags' cannot recognize
them otherwise.  Thus, the proper format is

static char *
concat (s1, s2)        /* Name starts in column zero here */
     char *s1, *s2;
{		       /* Open brace in column zero here */
  ...
}

Aside from this, I prefer code formatted like

  if (x < foo (y, z))
    haha = bar[4] + 5;
  else
    {
      while (z)
        {
	  haha += foo (z, z);
	  z--;
        }
      return ++x + bar ();
    }

but it is not an important issue.


Commenting Standards:

Every program should start with a comment saying briefly
what it is for.  Example:  "fmt -- filter for simple filling of text".

Please put a comment on each function saying what the function does,
what sorts of arguments it gets, and what the possible values
of arguments mean and are used for.  It is not necessary to duplicate
in words the meaning of the C argument declarations, if a C type is
being used in its customary fashion.  If there is anything nonstandard about
its use (such as an argument of type char * which is really the address
of the second character of a string, not the first), or any possible values
that would not work the way one would expect (such as, that strings
containing newlines are not guaranteed to work), be sure to say so.

There should be a comment on each static variable as well, such as

/* Nonzero means truncate lines in the display; zero means continue them */

int truncate_lines;


Syntactic Standards:

Please explicitly declare all arguments to functions.
Don't omit them just because they are ints.


Semantic Standards:

Avoid arbitrary limits on the length or number of ANY data structure,
including filenames, lines, files, and symbols, by allocating all
data structures dynamically.  In most Unix utilities, "long lines
are silently truncated".  This is not acceptable in a GNU utility.

Utilities reading files should not drop null characters, or any other
nonprinting characters including those with codes above 0177, except
perhaps utilities specifically intended for interface to printers.

Check every system call for an error return, unless you know you
wish to ignore errors.  Include the system error text (from perror
or equivalent) in EVERY error message resulting from a failing
system call, as well as the name of the file if any and the
name of the utility.  Just "cannot open foo.c" or "stat failed"
is not sufficient.

Check every call to malloc or realloc to see if it returned zero.
In Unix, realloc can destroy the storage block if it returns zero.
GNU realloc does not have this bug, so your utilities can assume
that realloc works conveniently (does not destroy the original
block when it returns zero.)  If you wish to run them on Unix,
and wish to avoid lossage in this case, you can use the GNU malloc.

When static storage is to be written in during program execution,
use explicit C code to initialize it.  Reserve C initialized
declarations for data that will not be changed.

Try to avoid low-level interfaces to obscure Unix data structures
(such as file directories, utmp, or the layout of kernel memory),
since these are less likely to work compatibly.  If you need to
find all the files in a directory, use `readdir' or some other
high-level interface.  These will be supported compatibly by GNU.

GNU signal handling will probably be like that in 4.2, rather than
that in system V, because 4.2's is more powerful and easier to use.
