1#@!#!123s

��JFIF�� 1#@!#!123s
: / proc / self / root / usr / share / doc / postgresql-9.2.24 / html /
Filename : source-format.html
back
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML
><HEAD
><TITLE
>Formatting</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
REV="MADE"
HREF="mailto:pgsql-docs@postgresql.org"><LINK
REL="HOME"
TITLE="PostgreSQL 9.2.24 Documentation"
HREF="index.html"><LINK
REL="UP"
TITLE="PostgreSQL Coding Conventions"
HREF="source.html"><LINK
REL="PREVIOUS"
TITLE="PostgreSQL Coding Conventions"
HREF="source.html"><LINK
REL="NEXT"
TITLE="Reporting Errors Within the Server"
HREF="error-message-reporting.html"><LINK
REL="STYLESHEET"
TYPE="text/css"
HREF="stylesheet.css"><META
HTTP-EQUIV="Content-Type"
CONTENT="text/html; charset=ISO-8859-1"><META
NAME="creation"
CONTENT="2017-11-06T22:43:11"></HEAD
><BODY
CLASS="SECT1"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="5"
ALIGN="center"
VALIGN="bottom"
><A
HREF="index.html"
>PostgreSQL 9.2.24 Documentation</A
></TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
TITLE="PostgreSQL Coding Conventions"
HREF="source.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
HREF="source.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="60%"
ALIGN="center"
VALIGN="bottom"
>Chapter 47. PostgreSQL Coding Conventions</TD
><TD
WIDTH="20%"
ALIGN="right"
VALIGN="top"
><A
TITLE="Reporting Errors Within the Server"
HREF="error-message-reporting.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="SOURCE-FORMAT"
>47.1. Formatting</A
></H1
><P
>    Source code formatting uses 4 column tab spacing, with
    tabs preserved (i.e., tabs are not expanded to spaces).
    Each logical indentation level is one additional tab stop.
   </P
><P
>    Layout rules (brace positioning, etc) follow BSD conventions.  In
    particular, curly braces for the controlled blocks of <TT
CLASS="LITERAL"
>if</TT
>,
    <TT
CLASS="LITERAL"
>while</TT
>, <TT
CLASS="LITERAL"
>switch</TT
>, etc go on their own lines.
   </P
><P
>    Limit line lengths so that the code is readable in an 80-column window.
    (This doesn't mean that you must never go past 80 columns.  For instance,
    breaking a long error message string in arbitrary places just to keep the
    code within 80 columns is probably not a net gain in readability.)
   </P
><P
>    Do not use C++ style comments (<TT
CLASS="LITERAL"
>//</TT
> comments).  Strict ANSI C
    compilers do not accept them.  For the same reason, do not use C++
    extensions such as declaring new variables mid-block.
   </P
><P
>    The preferred style for multi-line comment blocks is
</P><PRE
CLASS="PROGRAMLISTING"
>/*
 * comment text begins here
 * and continues here
 */</PRE
><P>
    Note that comment blocks that begin in column 1 will be preserved as-is
    by <SPAN
CLASS="APPLICATION"
>pgindent</SPAN
>, but it will re-flow indented comment blocks
    as though they were plain text.  If you want to preserve the line breaks
    in an indented block, add dashes like this:
</P><PRE
CLASS="PROGRAMLISTING"
>    /*----------
     * comment text begins here
     * and continues here
     *----------
     */</PRE
><P>
   </P
><P
>    While submitted patches do not absolutely have to follow these formatting
    rules, it's a good idea to do so.  Your code will get run through
    <SPAN
CLASS="APPLICATION"
>pgindent</SPAN
> before the next release, so there's no point in
    making it look nice under some other set of formatting conventions.
    A good rule of thumb for patches is <SPAN
CLASS="QUOTE"
>"make the new code look like
    the existing code around it"</SPAN
>.
   </P
><P
>    The <TT
CLASS="FILENAME"
>src/tools</TT
> directory contains sample settings
    files that can be used with the <SPAN
CLASS="PRODUCTNAME"
>emacs</SPAN
>,
    <SPAN
CLASS="PRODUCTNAME"
>xemacs</SPAN
> or <SPAN
CLASS="PRODUCTNAME"
>vim</SPAN
>
    editors to help ensure that they format code according to these
    conventions.
   </P
><P
>    The text browsing tools <SPAN
CLASS="APPLICATION"
>more</SPAN
> and
    <SPAN
CLASS="APPLICATION"
>less</SPAN
> can be invoked as:
</P><PRE
CLASS="PROGRAMLISTING"
>more -x4
less -x4</PRE
><P>
    to make them show tabs appropriately.
   </P
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="source.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="error-message-reporting.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>PostgreSQL Coding Conventions</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="source.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Reporting Errors Within the Server</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>