Postgresql coding conventions

Hi,
I have noticed two different coding conventions being followed in
postgres code base.

See e.g. function names in syslogger.c

static void set_next_rotation_time(void);
static void sigHupHandler(SIGNAL_ARGS);

and variable names in the same file

int bytes_in_logbuffer = 0;
char *currentLogDir;

Chapter 46 of the documentation does not say much about variable or
function naming.

While writing code or reviewing a path are we supposed to consider the
camel cased names correct or the under-score separated names correct?

Regards
Abbas
www.enterprisedb.com

Abbas wrote:
> I have noticed two different coding conventions being followed in
> postgres code base.
>
> See e.g. function names in syslogger.c
>
> static void set_next_rotation_time(void);
> static void sigHupHandler(SIGNAL_ARGS);
>
> and variable names in the same file
>
> int bytes_in_logbuffer = 0;
> char *currentLogDir;
>
> Chapter 46 of the documentation does not say much about variable or
> function naming.
>
> While writing code or reviewing a path are we supposed to consider the
> camel cased names correct or the under-score separated names correct?

Both styles are in use in different parts of the source tree, mainly for
historical reasons. The rule of thumb is to see what style is used in
the surrounding code, and follow that.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

Abbas wrote:
> Hi,
> I have noticed two different coding conventions being followed in
> postgres code base.
>
> See e.g. function names in syslogger.c
>
> static void set_next_rotation_time(void);
> static void sigHupHandler(SIGNAL_ARGS);
>
> and variable names in the same file
>
> int bytes_in_logbuffer = 0;
> char *currentLogDir;
>
> Chapter 46 of the documentation does not say much about variable or
> function naming.
>
> While writing code or reviewing a path are we supposed to consider the
> camel cased names correct or the under-score separated names correct?
>
>
>

I don't think we have a standard. If there is to be one I'll cast as
many votes as possible for the use of underscores.
readingWithoutSpacesReallySucks.

cheers

andrew

Abbas <abbas(dot)butt(at)enterprisedb(dot)com> writes:

> While writing code or reviewing a path are we supposed to consider the
> camel cased names correct or the under-score separated names correct?

Some parts of the code use the two to distinguish between functions local to
that module and functions that are part of the public api. In those cases
functions with capitals are part of the public api of the module and lower
case functions are internal functions or utility functions. Except for the
modules where it's the reverse...

And actually looking around I can't find any good examples of this where there
aren't exceptions. I don't like the idea of a massive cleanup patch for this
but if someone's doing major surgery on a module it could be worth fixing up
names in that module to be consistent at the same time.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's PostGIS support!

Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> Abbas <abbas(dot)butt(at)enterprisedb(dot)com> writes:
>> While writing code or reviewing a path are we supposed to consider the
>> camel cased names correct or the under-score separated names correct?

> Some parts of the code use the two to distinguish between functions local to
> that module and functions that are part of the public api. In those cases
> functions with capitals are part of the public api of the module and lower
> case functions are internal functions or utility functions. Except for the
> modules where it's the reverse...

Right --- there are enough different naming styles in the codebase now
that it seems pretty much hopeless to expect it ever to be just one style.
I think the most we can hope for now is "try to make your patch
consistent with nearby code". Which is definitely a point worth
considering for reviewers --- just don't expect that there's one true style.

> And actually looking around I can't find any good examples of this
> where there aren't exceptions. I don't like the idea of a massive
> cleanup patch for this but if someone's doing major surgery on a
> module it could be worth fixing up names in that module to be
> consistent at the same time.

If it's a total rewrite anyway, then of course you could use whatever
names you like. But for incremental changes I would vote against
changing names that aren't directly being touched by the patch. What
that would mainly accomplish is to cause fits for the poor sods who have
to back-patch bug fixes. I still routinely curse our decision to alter
pg_indent's comment-wrapping rules around 8.1, because it means that no
back-patch ever applies cleanly across the 8.1/8.2 boundary.

A contrary point here is that if you are changing a function's API,
or the meaning of a field, etc, it's often a good idea to intentionally
rename it; that guarantees that you won't miss fixing any references
to it.

regards, tom lane