Re: A small rant about coding style for backend functions

Bruce Momjian wrote:
> 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.

If someone submits a piece of code that's totally out of line with our
standards, we will ask him to resubmit.  This step could be avoided if
he knew what those standards were in the first place.

This doesn't have to be a bible on coding style.  A few guidelines
suffice.

PG_GETARG and the like are not fixed by pgindent though (which is what
spawned this whole discussion).  And in-house code (or pgFondry code),
which could also benefit by our coding style, will not be processed by
pgindent anyway.

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

I don't understand why would you link to an article about the value of
consistent coding style, and not provide a link to our own coding style.

I also don't understand why pgindent is assumed to be some sort of
silver bullet to solve all our coding style problems.  It is better if
we educate our developers instead of just having pgindent at the end of
the cycle deal with the messed up code.  Up to now, this education has
been one individual at a time, but it is much better if we can scale in
a way that every individual wastes only his own time learning our rules.

-- 
Alvaro Herrera       Valdivia, Chile   ICBM: S 39º 49' 18.1", W 73º 13' 56.4"
Thou shalt check the array bounds of all strings (indeed, all arrays), for
surely where thou typest "foo" someone someday shall type
"supercalifragilisticexpialidocious" (5th Commandment for C programmers)