PL/SQL Standards

+PL/SQL Standards

Prev	Chapter�12.�Engineering Standards	Next

PL/SQL Standards

By richardl@arsdigita.com and yon@arsdigita.com

@@ -12,19 +11,19 @@ our product will be useful long after the current people building and maintaining it are around. Following are some standards and guidelines that will help us achieve this goal: -

General

+
General
1. All PL/SQL code must be well documented. We must write code that is maintainable by others, this is especially true in our case because we are building an open source toolkit than anyone can download and browse the source code. So document like you are - trying to impress your "Introduction to Programming" professor or + trying to impress your "Introduction to Programming" professor or TA.
2. It is important to be consistent throughout an application as much as is possible given the nature of team development. This means carrying style and other conventions suchs as naming within an application, not just within one file. -
Code
1. +
Code
1. Encapsulation of related fuctionality is key to maintainability and upgradeability of our software. Try to bundle your code into packages @@ -55,16 +54,16 @@ show errors
2. - 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.
3. - 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.
4. - Always use the "show errors" SQL*Plus command after each PL/SQL + Always use the "show errors" SQL*Plus command after each PL/SQL block. It will help you debug when there are compilation errors in your PL/SQL code.
5. @@ -73,11 +72,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.)
       
      
@@ -109,22 +108,22 @@
         show errors
      
 
```
6. - Explicitly designate each parameter as "in," "out," or "inout." + Explicitly designate each parameter as "in," "out," or "inout."
7. Each parameter should be on its own line, with a tab after the parameter name, then in/out/inout, then a space, and finally the datatype.
8. Use %TYPE and %ROWTYPE whenever possible.
9. - Use 't' and 'f' for booleans, not the PL/SQL "boolean" datatype + Use 't' and 'f' for booleans, not the PL/SQL "boolean" datatype because it can't be used in SQL queries.
10. - 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 +137,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. -
Style
+ object_id and now they want to create the object with + that object_id. +

`Style`

Some general style guidelines to follow for the purpose of consistency across applications.

@@ -153,4 +152,4 @@ as possible to all source code readers.
Lowercase everything, with the exception of %TYPE and %ROWTYPE. -

($Id$)

Prev	Home	Next
ACS File Naming and Formatting Standards	Up	Appendix�C.�Using CVS with an OpenACS Site

docs@openacs.org

View comments on this page at openacs.org +

($Id$)

PL/SQL Standards

PL/SQL Standards

General

General

Code

Code

Style

Style

`Style`

`Style`