Re: A small rant about coding style for backend functions - Mailing list 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@sss.pgh.pa.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@momjian.us>        http://momjian.us EnterpriseDB
http://postgres.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +