1
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
8
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
10
HREF="mailto:pgsql-docs@postgresql.org"><LINK
12
TITLE="PostgreSQL 9.1beta1 Documentation"
13
HREF="index.html"><LINK
15
TITLE="PostgreSQL Coding Conventions"
16
HREF="source.html"><LINK
18
TITLE="PostgreSQL Coding Conventions"
19
HREF="source.html"><LINK
21
TITLE="Reporting Errors Within the Server"
22
HREF="error-message-reporting.html"><LINK
25
HREF="stylesheet.css"><META
26
HTTP-EQUIV="Content-Type"
27
CONTENT="text/html; charset=ISO-8859-1"><META
29
CONTENT="2011-04-27T21:20:33"></HEAD
35
SUMMARY="Header navigation table"
47
>PostgreSQL 9.1beta1 Documentation</A
56
TITLE="PostgreSQL Coding Conventions"
66
TITLE="PostgreSQL Coding Conventions"
74
>Chapter 47. PostgreSQL Coding Conventions</TD
80
TITLE="PostgreSQL Coding Conventions"
89
TITLE="Reporting Errors Within the Server"
90
HREF="error-message-reporting.html"
108
> Source code formatting uses 4 column tab spacing, with
109
tabs preserved (i.e., tabs are not expanded to spaces).
110
Each logical indentation level is one additional tab stop.
113
> Layout rules (brace positioning, etc) follow BSD conventions. In
114
particular, curly braces for the controlled blocks of <TT
124
>, etc go on their own lines.
127
> Limit line lengths so that the code is readable in an 80-column window.
128
(This doesn't mean that you must never go past 80 columns. For instance,
129
breaking a long error message string in arbitrary places just to keep the
130
code within 80 columns is probably not a net gain in readability.)
133
> Do not use C++ style comments (<TT
136
> comments). Strict ANSI C
137
compilers do not accept them. For the same reason, do not use C++
138
extensions such as declaring new variables mid-block.
141
> The preferred style for multi-line comment blocks is
143
CLASS="PROGRAMLISTING"
145
* comment text begins here
149
Note that comment blocks that begin in column 1 will be preserved as-is
153
>, but it will re-flow indented comment blocks
154
as though they were plain text. If you want to preserve the line breaks
155
in an indented block, add dashes like this:
157
CLASS="PROGRAMLISTING"
159
* comment text begins here
166
> While submitted patches do not absolutely have to follow these formatting
167
rules, it's a good idea to do so. Your code will get run through
171
> before the next release, so there's no point in
172
making it look nice under some other set of formatting conventions.
173
A good rule of thumb for patches is <SPAN
175
>"make the new code look like
176
the existing code around it"</SPAN
183
> directory contains sample settings
184
files that can be used with the <SPAN
195
editors to help ensure that they format code according to these
199
> The text browsing tools <SPAN
208
CLASS="PROGRAMLISTING"
212
to make them show tabs appropriately.
220
SUMMARY="Footer navigation table"
249
HREF="error-message-reporting.html"
259
>PostgreSQL Coding Conventions</TD
273
>Reporting Errors Within the Server</TD
b'\\ No newline at end of file'