Skip site navigation (1) Skip section navigation (2)

Re: A small rant about coding style for backend functions

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Brendan Jurd <direvus(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: A small rant about coding style for backend functions
Date: 2007-10-31 21:15:33
Message-ID: 200710312115.l9VLFXb11140@momjian.us (view raw or flat)
Thread:
Lists: pgsql-hackers
I have not forgotten this suggestion.  Do have any ideas what such a
list would look like?  Examples?

I think we have avoided more details in fear of scaring off coders. 
People usually follow our style as they gain experience.  Having a hard
list seems like it would be a lot of do's and don't's.

---------------------------------------------------------------------------

Brendan Jurd wrote:
> On 8/18/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > The main drawback to the V1-call-convention function call mechanism,
> > compared to ordinary C functions, is that you can't instantly see what
> > the function arguments are supposed to be.  I think that good coding
> > style demands ameliorating this by declaring and extracting all the
> > arguments at the top of the function.  The above example is bad enough,
> > but when you have to dig through a function of many lines looking for
> > GETARG calls in order to know what arguments it expects, it's seriously
> > annoying and unreadable.
> >
> > And another thing: use the correct extraction macro for the argument's
> > type, rather than making something up on the fly.  Quite aside from
> > helping the reader see what the function expects, the first example
> > above is actually *wrong*, as it will crash on toasted input.
> 
> This is all useful guidance.  My question is why it's not part of the
> developer documentation.  Which brings me around to a minor rant of my
> own.
> 
> All the developer FAQ has to say about coding style is that we use
> 4-space tabs for indentation, and that you should "merge seamlessly
> into the surrounding code".  That isn't much solace when the
> surrounding code is itself nigh unreadable or doesn't contain examples
> of what you are trying to do.
> 
> For postgres hacking newbies (such as myself), the lack of any obvious
> published coding standards for the project is daunting, and is bound
> to lead to those developers "filling in the blanks" with their own
> coding style biases.  Which means the patch reviewers need to spend
> time pointing out the flaws, and the submitter needs to spend time
> adjusting, testing and resubmitting ... it's all quite avoidable.
> 
> I humbly suggest that if the sort of valuable information posted by
> Tom here was documented instead of ranted to the mailing list, maybe
> you guys wouldn't have to do so much ranting =)
> 
> Cheers
> BJ
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings

-- 
  Bruce Momjian  <bruce(at)momjian(dot)us>        http://momjian.us
  EnterpriseDB                             http://postgres.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

In response to

Responses

pgsql-hackers by date

Next:From: Gevik BabakhaniDate: 2007-10-31 21:31:07
Subject: Re: Proposal TODO Item: SQL-language reference parameters by name
Previous:From: Magnus HaganderDate: 2007-10-31 20:56:38
Subject: Re: psql show dbsize?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group