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
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 |