| Server IP : 172.67.134.114 / Your IP : 162.159.115.42 Web Server : Apache/2.4.37 System : Linux almalinux.duckdns.org 4.18.0-553.111.1.el8_10.x86_64 #1 SMP Sun Mar 8 20:06:07 EDT 2026 x86_64 User : ricodeal ( 1046) PHP Version : 7.4.33 Disable Function : NONE MySQL : OFF | cURL : ON | WGET : ON | Perl : ON | Python : ON | Sudo : ON | Pkexec : ON Directory : /usr/share/doc/postgresql-docs/html/ |
Upload File : |
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>53.1. Formatting</title><link rel="stylesheet" type="text/css" href="stylesheet.css" /><link rev="made" href="[email protected]" /><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /><link rel="prev" href="source.html" title="Chapter 53. PostgreSQL Coding Conventions" /><link rel="next" href="error-message-reporting.html" title="53.2. Reporting Errors Within the Server" /></head><body><div xmlns="http://www.w3.org/TR/xhtml1/transitional" class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="5" align="center">53.1. Formatting</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="source.html" title="Chapter 53. PostgreSQL Coding Conventions">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="source.html" title="Chapter 53. PostgreSQL Coding Conventions">Up</a></td><th width="60%" align="center">Chapter 53. PostgreSQL Coding Conventions</th><td width="10%" align="right"><a accesskey="h" href="index.html" title="PostgreSQL 10.23 Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="error-message-reporting.html" title="53.2. Reporting Errors Within the Server">Next</a></td></tr></table><hr></hr></div><div class="sect1" id="SOURCE-FORMAT"><div class="titlepage"><div><div><h2 class="title" style="clear: both">53.1. Formatting</h2></div></div></div><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 <code class="literal">if</code>,
<code class="literal">while</code>, <code class="literal">switch</code>, 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 (<code class="literal">//</code> 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">“<span class="quote">make the new code look like
the existing code around it</span>”</span>.
</p><p> The <code class="filename">src/tools</code> 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 xmlns="http://www.w3.org/TR/xhtml1/transitional" class="navfooter"><hr></hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="source.html" title="Chapter 53. PostgreSQL Coding Conventions">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="source.html" title="Chapter 53. PostgreSQL Coding Conventions">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="error-message-reporting.html" title="53.2. Reporting Errors Within the Server">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 53. PostgreSQL Coding Conventions </td><td width="20%" align="center"><a accesskey="h" href="index.html" title="PostgreSQL 10.23 Documentation">Home</a></td><td width="40%" align="right" valign="top"> 53.2. Reporting Errors Within the Server</td></tr></table></div></body></html>