Thread: function and variable names

function and variable names

From
Brian Bruns
Date:
Hi all,

I've started separating out the general socket code away from the 
frontend/backend protocol code to make way for the inclusion of other 
network protocols, and have some style questions.

I see a lot of the code has K&R style names such as foo_bar_baz() and some 
has FooBarBaz() style.  Is one a newer style and one an older? or is it 
just a function of different developers working on the code?  Personally I 
like K&R style but will of course adapt to whatever is the consensus view.

Also, while I'm in there (and after reading the threads thread), I'll be 
moving some of the globals/statics to either the Port structure or 
protocol specific structures.  Anyone have any other special requests?

Brian



Re: function and variable names

From
Tom Lane
Date:
Brian Bruns <camber@ais.org> writes:
> I see a lot of the code has K&R style names such as foo_bar_baz() and some 
> has FooBarBaz() style.  Is one a newer style and one an older? or is it 
> just a function of different developers working on the code?

The latter; we have never tried to enforce any particular naming style.
I'd counsel trying to match the style of the existing code near where
you are working.

> Also, while I'm in there (and after reading the threads thread), I'll be 
> moving some of the globals/statics to either the Port structure or 
> protocol specific structures.  Anyone have any other special requests?

Don't overdo it.  There will never be more than one postmaster thread,
even if we have threads at all; ergo no good reason to avoid static
storage of things that are only used by the postmaster.

The Port structure is actually a leftover from back when the postmaster
did its own poor-man's-multithreading to handle concurrent client
authentication operations.  I am not sure we really need/want it at all
anymore.  I'd suggest thinking in terms of making the code simpler and
more readable, rather than worrying about whether it can be
multithreaded.
        regards, tom lane