Brendan Jurd wrote:
> On Nov 9, 2007 3:17 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > We want patch submitters to spend their time on patches, not learning
> > our style. The fact is that pgindent is a silver bullet in some ways.
>
> Well there's a lot of support for the idea of pgindent bei
On Nov 9, 2007 3:17 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> We want patch submitters to spend their time on patches, not learning
> our style. The fact is that pgindent is a silver bullet in some ways.
Well there's a lot of support for the idea of pgindent being good
enough to establish a
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> If someone submits a piece of code that's totally out of line with our
> standards, we will ask him to resubmit. This step could be avoided if
> he knew what those standards were in the first place.
True, but "make it look like what you see" is more th
Alvaro Herrera wrote:
> > > Having said that, there are two or three tips worth knowing about
> > > pg_indent's behavior, like when and how to use dashes to prevent
> > > comment blocks from being re-flowed. But it's a short list.
>
> If someone submits a piece of code that's totally out of line
Bruce Momjian wrote:
> Tom Lane wrote:
> > "Brendan Jurd" <[EMAIL PROTECTED]> writes:
> > > If Postgres did have something akin to the Python C style guide, that
> > > would be excellent. But all we've got is a standard tabstop of four
> > > spaces and the five words "Our standard format BSD style
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>
>> Having said that, there are two or three tips worth knowing about
>> pg_indent's behavior, like when and how to use dashes to prevent
>> comment blocks from being re-flowed. But it's a short list.
>
> Agreed, and the developer's F
Tom Lane wrote:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
> > If Postgres did have something akin to the Python C style guide, that
> > would be excellent. But all we've got is a standard tabstop of four
> > spaces and the five words "Our standard format BSD style". Don't you
> > think that co
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> If Postgres did have something akin to the Python C style guide, that
> would be excellent. But all we've got is a standard tabstop of four
> spaces and the five words "Our standard format BSD style". Don't you
> think that comes across as pretty weak
Gregory Stark wrote:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
>
> > If Postgres did have something akin to the Python C style guide, that
> > would be excellent. But all we've got is a standard tabstop of four
> > spaces and the five words "Our standard format BSD style". Don't you
> > think
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> If Postgres did have something akin to the Python C style guide, that
> would be excellent. But all we've got is a standard tabstop of four
> spaces and the five words "Our standard format BSD style". Don't you
> think that comes across as pretty weak
On Nov 8, 2007 2:49 AM, Gregory Stark <[EMAIL PROTECTED]> wrote:
>
> None of these points in here seem at all analogous to the important kind of
> style details like what Tom was pointing out about using GETARG_* at the top
> of your function to make the argument types clear.
>
I would love to see
Gregory Stark wrote:
>
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
>
> > They are clear, useful and easy to understand.
> >
> > [1] http://www.python.org/dev/peps/pep-0007/
> > [2] http://www.python.org/dev/peps/pep-0008/
>
> I didn't look at the second but the first at least is a good example
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> They are clear, useful and easy to understand.
>
> [1] http://www.python.org/dev/peps/pep-0007/
> [2] http://www.python.org/dev/peps/pep-0008/
I didn't look at the second but the first at least is a good example of a
style guide which is *not* useful.
On 11/8/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> The problem is that a full list would be harder to understand than just
> looking at the existing code and following it, or taking suggestions
> from us as we review the patch.
>
What makes you say it would be necessarily harder to understand?
Brendan Jurd wrote:
> On 11/6/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> >
> > I understand your suggestions but it seems there would be too many
> > individual items to be readable. Can you suggest a full list so we can
> > get an idea of how long it would be?
>
> If the body of material on
On 11/6/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
> I understand your suggestions but it seems there would be too many
> individual items to be readable. Can you suggest a full list so we can
> get an idea of how long it would be?
If the body of material on writing good Postgres code becomes
I understand your suggestions but it seems there would be too many
individual items to be readable. Can you suggest a full list so we can
get an idea of how long it would be?
---
Brendan Jurd wrote:
> On 11/1/07, Bruce Momj
On 11/1/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
> I have not forgotten this suggestion. Do have any ideas what such a
> list would look like? Examples?
>
Thanks for the reply Bruce.
Code examples, perhaps with "good style" and "bad style" versions to
illustrate each point.
In the case o
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.
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
20 matches
Mail list logo
