begriffs open source - ai-pg/blob - full-docs/src/sgml/html/source-format.html

   1 <?xml version="1.0" encoding="UTF-8" standalone="no"?>
   2 <!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>55.1. Formatting</title><link rel="stylesheet" type="text/css" href="stylesheet.css" /><link rev="made" href="pgsql-docs@lists.postgresql.org" /><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /><link rel="prev" href="source.html" title="Chapter 55. PostgreSQL Coding Conventions" /><link rel="next" href="error-message-reporting.html" title="55.2. Reporting Errors Within the Server" /></head><body id="docContent" class="container-fluid col-10"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="5" align="center">55.1. Formatting</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="source.html" title="Chapter 55. PostgreSQL Coding Conventions">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="source.html" title="Chapter 55. PostgreSQL Coding Conventions">Up</a></td><th width="60%" align="center">Chapter 55. PostgreSQL Coding Conventions</th><td width="10%" align="right"><a accesskey="h" href="index.html" title="PostgreSQL 18.0 Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="error-message-reporting.html" title="55.2. Reporting Errors Within the Server">Next</a></td></tr></table><hr /></div><div class="sect1" id="SOURCE-FORMAT"><div class="titlepage"><div><div><h2 class="title" style="clear: both">55.1. Formatting <a href="#SOURCE-FORMAT" class="id_link">#</a></h2></div></div></div><p>
   3     Source code formatting uses 4 column tab spacing, with
   4     tabs preserved (i.e., tabs are not expanded to spaces).
   5     Each logical indentation level is one additional tab stop.
   6    </p><p>
   7     Layout rules (brace positioning, etc.) follow BSD conventions.  In
   8     particular, curly braces for the controlled blocks of <code class="literal">if</code>,
   9     <code class="literal">while</code>, <code class="literal">switch</code>, etc. go on their own lines.
  10    </p><p>
  11     Limit line lengths so that the code is readable in an 80-column window.
  12     (This doesn't mean that you must never go past 80 columns.  For instance,
  13     breaking a long error message string in arbitrary places just to keep the
  14     code within 80 columns is probably not a net gain in readability.)
  15    </p><p>
  16     To maintain a consistent coding style, do not use C++ style comments
  17     (<code class="literal">//</code> comments).  <span class="application">pgindent</span>
  18     will replace them with <code class="literal">/* ... */</code>.
  19    </p><p>
  20     The preferred style for multi-line comment blocks is
  21 </p><pre class="programlisting">
  22 /*
  23  * comment text begins here
  24  * and continues here
  25  */
  26 </pre><p>
  27     Note that comment blocks that begin in column 1 will be preserved as-is
  28     by <span class="application">pgindent</span>, but it will re-flow indented comment blocks
  29     as though they were plain text.  If you want to preserve the line breaks
  30     in an indented block, add dashes like this:
  31 </p><pre class="programlisting">
  32     /*----------
  33      * comment text begins here
  34      * and continues here
  35      *----------
  36      */
  37 </pre><p>
  38    </p><p>
  39     While submitted patches do not absolutely have to follow these formatting
  40     rules, it's a good idea to do so.  Your code will get run through
  41     <span class="application">pgindent</span> before the next release, so there's no point in
  42     making it look nice under some other set of formatting conventions.
  43     A good rule of thumb for patches is <span class="quote">“<span class="quote">make the new code look like
  44     the existing code around it</span>”</span>.
  45    </p><p>
  46     The <code class="filename">src/tools/editors</code> directory contains sample settings
  47     files that can be used with the <span class="productname">Emacs</span>,
  48     <span class="productname">xemacs</span> or <span class="productname">vim</span>
  49     editors to help ensure that they format code according to these
  50     conventions.
  51    </p><p>
  52     If you'd like to run <span class="application">pgindent</span> locally
  53     to help make your code match project style, see
  54     the <code class="filename">src/tools/pgindent</code> directory.
  55    </p><p>
  56     The text browsing tools <span class="application">more</span> and
  57     <span class="application">less</span> can be invoked as:
  58 </p><pre class="programlisting">
  59 more -x4
  60 less -x4
  61 </pre><p>
  62     to make them show tabs appropriately.
  63    </p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="source.html" title="Chapter 55. PostgreSQL Coding Conventions">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="source.html" title="Chapter 55. PostgreSQL Coding Conventions">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="error-message-reporting.html" title="55.2. Reporting Errors Within the Server">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 55. PostgreSQL Coding Conventions </td><td width="20%" align="center"><a accesskey="h" href="index.html" title="PostgreSQL 18.0 Documentation">Home</a></td><td width="40%" align="right" valign="top"> 55.2. Reporting Errors Within the Server</td></tr></table></div></body></html>