Re: Postgresql coding conventions

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