Re: A small rant about coding style for backend functions

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