source: branches/1.5/STYLE

Last change on this file was 4261, checked in by robe, 7 years ago

forgot to save last change

File size: 2.3 KB
Line 
1Coding Style Guidelines for PostGIS
2-----------------------------------
3
4:Preamble:
5
6PostGIS was created over many years, by many different people, some in a
7hurry. As a result, the existing coding style is all over the map. We
8recognize this, and understand it will be the work of many years before
9PostGIS has a consistently named internal set of functions, but,
10we can dream.
11
12If new functions follow this guideline, if we do a little rennovation work
13from time to time, we will eventually get there.
14
15
16:Formatting:
17
18All C code should use an ANSI standard formatting with tabs for block
19indenting. When not block indenting, use spaces. To convert a file
20to the standard format use:
21
22  astyle --style=ansi --indent=tab
23
24Do not get too happy with this command. If you want to re-format a file you
25are working on:
26
27 a) run astyle on it
28 b) commit
29 c) do your work
30 d) commit
31 e) if you are really finicky run astyle again
32 f) commit
33
34The idea is to avoid combining style-only commits and commits that change
35logic, so the logic commits are easier to read.
36
37Macros should be ALL_UPPERCASE.
38Enumerations should be ALL_UPPERCASE.
39
40Comments should be written in C style (/* .... */) and not C++ style (//)
41When describing a function,  the description should be right above the function and should start with /**
42This is so the function description can be picked up by the doxygen autodocumentor.  For example
43
44/**
45 * Does something funny
46 */
47double funny_function(POINT2D *p1, POINT2D *p2, POINT2D *q){
48        funny stuff here;
49}
50
51More advanced commenting
52/**
53 * Does something funny
54 *
55 * @param p1       : first point
56 * @param p2     : second point
57 * @param q   : the quiet point
58 *
59 * @return a funny double number
60 */
61double funny_function(POINT2D *p1, POINT2D *p2, POINT2D *q){
62        funny stuff here;
63}
64
65
66:Naming:
67
68For ./liblwgeom:
69
70- Files should be named with an lw prefix.
71- Functions should have an lw prefix (lw_get_point).
72- Function names should use underscores, not camel case.
73- Function names should indicate the geometry type of inputs
74  if relevant (lwline_split)
75
76For ./postgis:
77
78- C functions called by the back-end directly (function(PG_FUNCTION_ARGS))
79  should be named to match their most likely SQL alias. So
80  the SQL ST_Distance(geometry) maps to the C function
81  ST_Distance(PG_FUNCTION_ARG)
82- C utility functions should be prefixed with pgis_ (lower case)
83
Note: See TracBrowser for help on using the repository browser.