</para>
  </formalpara>

  <formalpara>
    <title>Illegal</title>
   <para>
    <quote>Illegal</quote> stands for a violation of the law, the rest is
    <quote>invalid</quote>. Better yet, say why it's invalid.
   </para>
  </formalpara>

  <formalpara>
    <title>Unknown</title>
   <para>
    Try to avoid <quote>unknown</quote>.  Consider <quote>error: unknown
    response</quote>.  If you don't know what the response is, how do you know
    it's erroneous? <quote>Unrecognized</quote> is often a better choice.
    Also, be sure to include the value being complained of.
<programlisting>
BAD:    unknown node type
BETTER: unrecognized node type: 42
</programlisting>
   </para>
  </formalpara>

  <formalpara>
    <title>Find vs. Exists</title>
   <para>
    If the program uses a nontrivial algorithm to locate a resource (e.g., a
    path search) and that algorithm fails, it is fair to say that the program
    couldn't <quote>find</quote> the resource.  If, on the other hand, the
    expected location of the resource is known but the program cannot access
    it there then say that the resource doesn't <quote>exist</quote>.  Using
    <quote>find</quote> in this case sounds weak and confuses the issue.
   </para>
  </formalpara>

  <formalpara>
    <title>May vs. Can vs. Might</title>
   <para>
    <quote>May</quote> suggests permission (e.g., "You may borrow my rake."),
    and has little use in documentation or error messages.
    <quote>Can</quote> suggests ability (e.g., "I can lift that log."),
    and <quote>might</quote> suggests possibility (e.g., "It might rain
    today.").  Using the proper word clarifies meaning and assists
    translation.
   </para>
  </formalpara>

  <formalpara>
    <title>Contractions</title>
   <para>
    Avoid contractions, like <quote>can't</quote>;  use
    <quote>cannot</quote> instead.
   </para>
  </formalpara>

  <formalpara>
    <title>Non-negative</title>
   <para>
    Avoid <quote>non-negative</quote> as it is ambiguous
    about whether it accepts zero.  It's better to use
    <quote>greater than zero</quote> or
    <quote>greater than or equal to zero</quote>.
   </para>
  </formalpara>

  </simplesect>

  <simplesect id="error-style-guide-spelling">
   <title>Proper Spelling</title>

   <para>
    Spell out words in full.  For instance, avoid:
  <itemizedlist>
   <listitem>
    <para>
     spec
    </para>
   </listitem>
   <listitem>
    <para>
     stats
    </para>
   </listitem>
   <listitem>
    <para>
     parens
    </para>
   </listitem>
   <listitem>
    <para>
     auth
    </para>
   </listitem>
   <listitem>
    <para>
     xact
    </para>
   </listitem>
  </itemizedlist>
   </para>

   <para>
    Rationale: This will improve consistency.
   </para>

  </simplesect>

  <simplesect id="error-style-guide-localization">
   <title>Localization</title>

   <para>
    Keep in mind that error message texts need to be translated into other
    languages.  Follow the guidelines in <xref linkend="nls-guidelines"/>
    to avoid making life difficult for translators.
   </para>
  </simplesect>

  </sect1>

  <sect1 id="source-conventions">
   <title>Miscellaneous Coding Conventions</title>

   <simplesect id="source-conventions-c-standard">
    <title>C Standard</title>
    <para>
     Code in <productname>PostgreSQL</productname> should only rely on language
     features available in the C99 standard. That means a conforming
     C99 compiler has to be able to compile postgres, at least aside
     from a few platform dependent pieces.
    </para>
    <para>
     A few features included in the C99 standard are, at this time, not
     permitted to be used in core <productname>PostgreSQL</productname>
     code. This currently includes variable length arrays, intermingled
     declarations and code, <literal>//</literal> comments, universal
     character names. Reasons for that include portability and historical
     practices.
    </para>
    <para>
     Features from later revisions