On 2014-09-04 2:28 PM, I wrote:
> On 9/4/14 2:04 PM, Pavel Stehule wrote:
>> for example best practices for PL/SQL by Steven Feuerstein
>
> I'll spend some time with that book to have a better idea on where
> you're coming from.
I've read through this book twice now. Some observations on things we
don't follow:
- We don't use the exact hungarian notation -ish convention for
naming stuff. I don't see that as a bad thing. - Granted, we could be using the myfield tablename.columnname%TYPE;
probablymore. On the other hand, sometimes you would prefer to not
have all your types in your functions change transparently after an
ALTER TABLE. - The book takes the "single exit point" thinking to an extreme. I
don't agree with that, regardless of the language (and thus I might not
necessarily always follow it). - The book says "Encapsulate INSERT, UPDATE, and DELETE statements
behind procedure calls", which quite directly contradicts what you said
earlier.
The rest of the stuff we follow in our codebase as far as I can tell
(except the Oracle-specific stuff, obviously).
But further, even if we did follow every single one of the above points
perfectly, it wouldn't change the point we're trying to make. What
we're doing is following what the book dedicated an entire chapter to:
Defensive Programming. Enforcing that that UPDATE affected exactly one
row? Defensive Programming.
.marko
