Index: openacs-4/packages/acs-core-docs/www/eng-standards-plsql.adp =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/acs-core-docs/www/eng-standards-plsql.adp,v diff -u -r1.1.2.3 -r1.1.2.4 --- openacs-4/packages/acs-core-docs/www/eng-standards-plsql.adp 28 Sep 2015 07:54:14 -0000 1.1.2.3 +++ openacs-4/packages/acs-core-docs/www/eng-standards-plsql.adp 23 Jun 2016 08:32:45 -0000 1.1.2.4 @@ -25,8 +25,8 @@ 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 -TA.

  • It is important to be consistent throughout an application as +trying to impress your "Introduction to Programming" +professor or TA.

  • 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.

  • @@ -69,12 +69,13 @@ 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 -block. It will help you debug when there are compilation errors in -your PL/SQL code.

  • +package bodies, and triggers.

  • 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.

  • Name parameters as simply as possible, i.e., use the column name -if the parameter corresponds to a table column. We're deprecating -the v_* and *_in syntax in favor of named parameters notation:

    +if the parameter corresponds to a table column. We're
    +deprecating the v_* and *_in syntax in favor of named parameters
    +notation:

     
             acs_user.create(first_names => 'Jane', last_name => 'Doe', etc.)
           
    @@ -107,11 +108,12 @@
             show errors
          
     
    -
  • Explicitly designate each parameter as "in," "out," or -"inout."

  • Each parameter should be on its own line, with a tab after the +

  • Explicitly designate each parameter as "in," +"out," or "inout."

  • 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.

  • Use %TYPE and %ROWTYPE whenever possible.

  • Use 't' and 'f' for booleans, not the PL/SQL "boolean" datatype -because it can't be used in SQL queries.

  • +datatype.

  • Use %TYPE and %ROWTYPE whenever possible.

  • 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, party.new, etc.) should optionally accept an ID:

    
    @@ -140,8 +142,8 @@
     browsers. This means that we should try to make it as consistent as
     possible to all source code readers.

  • Lowercase everything, with the exception of %TYPE and %ROWTYPE.

  • -
    ($‌Id: plsql.xml,v 1.6 2006/07/17 05:38:37 -torbenb Exp $)
    +
    ($‌Id: eng-standards-plsql.html,v 1.49.2.10 +2016/06/21 07:44:36 gustafn Exp $)