54.1. Formatting

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.

Layout rules (brace positioning, etc.) follow BSD conventions. In particular, curly braces for the controlled blocks of if , while , switch , etc. go on their own lines.

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.)

To maintain a consistent coding style, do not use C++ style comments ( // comments). pgindent will replace them with /* ... */ .

The preferred style for multi-line comment blocks is

/*
 * comment text begins here
 * and continues here
 */

Note that comment blocks that begin in column 1 will be preserved as-is by pgindent , 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:

    /*----------
     * comment text begins here
     * and continues here
     *----------
     */

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 pgindent 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 " make the new code look like the existing code around it " .

The src/tools/editors directory contains sample settings files that can be used with the Emacs , xemacs or vim editors to help ensure that they format code according to these conventions.

If you'd like to run pgindent locally to help make your code match project style, see the src/tools/pgindent directory.

The text browsing tools more and less can be invoked as:

more -x4
less -x4

to make them show tabs appropriately.