Best Practices PL/SQL (2)

Some time ago (maybe a little to long) I wrote an blog entry about best practices in PL/SQL. I stared then some blog entries that I never finish writing so now I will make then public even unfinished.

One of the topics I mention in that first best practices entry was coding standards and naming conventions. Steven Feuerstein wrote recently an article presenting his ideas about that an updated and "not all-over the place" format.

I will talk here about the rules that he mention (june 2009) I follow and the ones I have trouble with.
I will number the rules according to the other they appear the May 27 2009 version
(SF :-) P for principles, G for general guidelines, N for naming)



SF_P1. "(...)If I had to choose between highly standardized, but obscure names or nonstandardized, but highly descriptive names, I would always go for the latter."
I agree ...SAP like names are very cryptic

SF_P2. "Normalize thy names: I try to avoid following conventions that introduce redundancy.(...)"
Maybe...
1. If you are not using a good IDE the get_ at the beginning helps you figuring out where are the functions.
2. using get_ makes the code more readable

SF_P3. "Upper-case non-application identifiers (that is, elements of the base PL/SQL language and Oracle built-ins) and lower-case application-specific elements.(...)Camel notation (maxSalary) is something to be avoided in caseinsensitive
PL/SQL(...)"
As I use Sql Navigator formatter I have to agree with this one. I like the camel notation that I used in NeXTStep and OpenStep, but for a caseinsensitive language it make no sense to me to use it (no way for the compiler/formatter to check it and to inforce it on the programmer).

SF_P4. "Make plural anything that contains multiple pieces of information: relational tables and collections, for the most part.(...)
Agree

SF_P5. "If the value of a variable will not (should not) change within the scope in which it is defined, I declare it to be a constant and use a c_ or gc_ prefix to indicate that it is a constant."
I use lc (local constant) and gc (global constant).

SF_P6 "Whenever the variable is based on (with %TYPE or %ROWTYPE) and/or contains
data retrieved from a table or column in a table, the "root name" of the identifier (...) should be the same as the element from which it is defined."
Sometimes...For now I think that it makes no sense to change every line of code if a table name changed, but not the meaning in the program context.
For instance I had a table with the employees addresses and now that table changed to person addresses (changing it's name), to explain that nows it also has some other addresses (contacts, costumers, etc.). For the program that only shows the employee data (and address) I would only change the table "connection" but not the variable name from lrt_employee_address to lrt_person_address.


To be continued...


P.S.
I already wrote in SF page but I will post here also my answers to SF "Things I still wonder about" questions.
How to distinguish between all the levels of scope between global (package level)
and local (in the current block). What if the current block is a local subprogram
within another subprogram?
I use g for global l for local and ll, lll (2 l's, 3l's, etc.) for depth procedures/functions ... anonymous blocks uses the same convention as the non-anonymous block there are.

Should functions and procedures without any arguments be invoked with "()"
after the subprogram name?
I use that but I do not enforce it on my team. I think the code gets more readable that way.