On 8/18/07, Tom Lane <[EMAIL PROTECTED]> 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
