Coding Style Guidelines for PostGIS
-----------------------------------

:Preamble:

PostGIS was created over many years, by many different people, some in a 
hurry. As a result, the existing coding style is all over the map. We 
recognize this, and understand it will be the work of many years before
PostGIS has a consistently named internal set of functions, but, 
we can dream. 

If new functions follow this guideline, if we do a little rennovation work
from time to time, we will eventually get there.


:Formatting:

All C code should use an ANSI standard formatting with tabs for block 
indenting. When not block indenting, use spaces. To convert a file
to the standard format use:

  astyle --style=ansi --indent=tab

Do not get too happy with this command. If you want to re-format a file you
are working on:

 a) run astyle on it
 b) commit
 c) do your work
 d) commit
 e) if you are really finicky run astyle again
 f) commit

The idea is to avoid combining style-only commits and commits that change
logic, so the logic commits are easier to read.

Macros should be ALL_UPPERCASE. 
Enumerations should be ALL_UPPERCASE.

Comments should be written in C style (/* .... */) and not C++ style (//)


:Naming:

For liblwgeom:

- Files should be named with an lw prefix.
- Functions should have an lw prefix (lw_get_point).
- Function names should use underscores, not camel case.
- Function names should indicate the geometry type of inputs
  if relevant (lwline_split)

For lwgeom:

- C functions called by the back-end directly (function(PG_FUNCTION_ARGS)) 
  should be named to match their most likely SQL alias. So
  the SQL ST_Distance(geometry) maps to the C function
  ST_Distance(PG_FUNCTION_ARG)
- C utility functions should be prefixed with pgis_ (lower case)