Re: A small rant about coding style for backend functions

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