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 <[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 -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
