future coding standards for stored procedure names

[Chris Travers <..hidden..>]

Hi;

I am thinking one area we probably want to firm up our coding
standards is in the area of stored procedure names.  There are two
fundamental issues I see with our current approach in 1.3.  The first
is that the double underscore approach really doesn't work well except
in the case of roles where it is enforced by the application.  The
second is that verbs end up going wherever they seem like they should,
and this makes the API somewhat hard to learn.

I would suggest instead think about this and try to standardize as
much as possible going forward, at least into 1.4.

Basically I think we should standardize on one of the following two formats:

${class_name}_${sep}_${noun}_${verb}

or

${class_name}_${sep}_${verb}_${noun}

This leads to two questions:

1)  Which of these is preferred?  I am leaning towards the second
because it suggests a sort of Subject-Verb-Object syntax relatively
familiar to us Indo-European speakers (languages which include
English, Spanish, etc).  In cases where the second noun doesn't apply,
it's pretty clear also.  So for example company_pkg_get (with pkg as
the $sep) is clear, as is company_pkg_get_credit_accts.  Here we know
we have a company and we are getting related credit accounts.

2)  What kidns of separators should we use?  One option might be to
look at non-alphanumeric characters that could be differentiated by by
sight, something like:

"company_:::_get"

The big issue here is that omitting the double quotes renders this
unusable and this makes manual use a little more bothersome, and this
could lead to dangerous errors if new operators are ever added which
conflict with the choices made.  However if we go with this route, we
can remove the underscores around sep, leading to something like
"company:::get" or "company->get"

The second possibility is to use an alphanumeric string to
separate.the components.  Say, pkg in the above example.

I am personally leaning towards the "company->get" syntax (and
"company->get_credit_accounts").  I think it is the easiest to read,
and most frameworks are likely to automatically quote the identifier
anyway.

What does everyone else think?

Best Wishes,
Chris Travers