Re: A small rant about coding style for backend functions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Brendan Jurd" <direvus(at)gmail(dot)com>
Cc: "Gregory Stark" <stark(at)enterprisedb(dot)com>, "Bruce Momjian" <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org, "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>
Subject: Re: A small rant about coding style for backend functions
Date: 2007-11-08 14:58:49
Message-ID: 24178.1194533929@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Brendan Jurd" <direvus(at)gmail(dot)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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2007-11-08 15:01:09 Re: Estimation problem with a LIKE clause containing a /
Previous Message Peter Eisentraut 2007-11-08 14:22:10 Re: interval * numeric operator