Gregory Stark <[EMAIL PROTECTED]> writes:
> Abbas <[EMAIL PROTECTED]> 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
