Tom Lane wrote:
> "Brendan Jurd" <[EMAIL PROTECTED]> 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 <A href=
"http://ezine.daemonnews.org/200112/single_coding_style.html";>article</A>
describes the value of a consistent coding style.</P>
<P><I>pgindent</I> is run on all source files just before each beta
test period. It auto-formats all source files to make them
consistent. Comment blocks that need specific line breaks should be
formatted as <I>block comments,</I> where the comment starts as
<CODE>/*------</CODE>. These comments will not be reformatted in
any way.</P>
--
Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
