Encapsulation of related fuctionality is key to maintainability
and upgradeability of our software. Try to bundle your code into
packages
@@ -55,13 +55,13 @@
show errors
- Always use create or replace procedure|function
+ Always use create or replace procedure|function
<proc_or_func_name>. It makes reloading packages much
easier and painless to someone who is upgrading or fixing a bug.
- Always qualify end statements, i.e., the
- end statement for a package should be end
- <package_name>;, not just end;; same
+ Always qualify end statements, i.e., the
+ end statement for a package should be end
+ <package_name>;, not just end;; same
goes for procedures, functions, package bodies, and triggers.
Always use the "show errors" SQL*Plus command after each PL/SQL
@@ -73,11 +73,11 @@
the v_* and *_in syntax in favor of named parameters notation:
-
+
acs_user.create(first_names => 'Jane', last_name => 'Doe', etc.)
instead of
-
+
acs_user.create(first_names_in => 'Jane', last_name_in => 'Doe', etc.)
@@ -120,11 +120,11 @@
Use 't' and 'f' for booleans, not the PL/SQL "boolean" datatype
because it can't be used in SQL queries.
- All new functions (e.g., acs_object.new,
+ All new functions (e.g., acs_object.new,
party.new, etc.) should optionally accept an ID:
-
+
create or replace package acs_object
as
function new (
@@ -138,12 +138,12 @@
- takes the optional argument object_id. Do this to
+ takes the optional argument object_id. Do this to
allow people to use the same API call when they are doing double
click protection, that is, tehy have already gotten an
- object_id and now they want to create the object with
- that object_id.
-
