Tom Lane wrote:
> "Brendan Jurd" <direvus@gmail.com> writes:
> > If Postgres did have something akin to the Python C style guide, that
> > would be excellent. But all we've got is a standard tabstop of four
> > spaces and the five words "Our standard format BSD style". Don't you
> > think that comes across as pretty weak for a project of this size and
> > significance?
>
> The reason it's not necessary to be very explicit about that is simple:
> pg_indent. Your code *will* conform to the layout standards by the
> time it's released ;-). Now it's still a good idea to make new code
> look roughly like what you see there already, because if you go too
> far overboard in ignoring line-length or comment layout conventions,
> the code may look a bit awful when pg_indent gets done with it.
> But I see no need to burden authors with any advice more detailed
> than "make it look like what you see".
>
> Having said that, there are two or three tips worth knowing about
> pg_indent's behavior, like when and how to use dashes to prevent
> comment blocks from being re-flowed. But it's a short list.
Agreed, and the developer's FAQ already has this:
<P><I>pgindent</I> will the format code by specifying flags to your operating system's utility <I>indent.</I> This
<Ahref= "http://ezine.daemonnews.org/200112/single_coding_style.html">article</A> describes the value of a
consistentcoding style.</P>
<P><I>pgindent</I> is run on all source files just before each beta test period. It auto-formats all source files
tomake them consistent. Comment blocks that need specific line breaks should be formatted as <I>block comments,</I>
wherethe comment starts as <CODE>/*------</CODE>. These comments will not be reformatted in any way.</P>
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://postgres.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
