This document provides guidelines for PL/SQL coding conventions. It discusses naming conventions, coding style and formatting, commenting practices, and best practices for literals, data types, flow control, exception handling, and dynamic SQL. Specific recommendations include using meaningful names, consistent indentation, commenting blocks for views and triggers, avoiding hardcoded values, anchoring variables to types, always labeling loops, and using bind variables in dynamic SQL.

1. PL/SQL Coding Conventions fang.yu@moodys.com Dec 28, 2010

2. Agenda Naming Conventions Coding Style, Format and Comments PL/SQL Best Practices

4. Some Facts that Matter

5. An Appetizer

6. General Guidelines

8. Higher quality, more robust

9. Better products

14. 1.5 Naming Conventions for Variables

15. 1.6 Naming Conventions for Cursors

16. 1.7 Naming Conventions for Records and Collections

17. 1.8 Naming Conventions for Database Objects

19. Some Examples

20. Tools that format PL/SQL

21. Code Commenting

23. Indention using tab or 3 spaces. Keep it consistent!

24. One command per line.

25. Specify columns explicitly in SELECT and INSERT statements

26. SQL keywords are right-aligned / left-aligned within a SQL command. Keep it consistent!PROCEDURE set_salary(p_empno_in IN emp.empno%TYPE) IS CURSOR l_emp_cur(p_empnoemp.empno%TYPE) IS SELECT ename ,sal FROM emp WHERE empno = p_empno ORDER BY ename; l_empl_emp_cur%ROWTYPE; l_new_salemp.sal%TYPE; BEGIN OPEN l_emp_cur(p_empno_in); FETCH l_emp_cur INTO l_emp; CLOSE l_emp_cur; -- get_new_salary (p_empno_in => in_empno , p_sal_out => l_new_sal); -- Check whether salary has changed IF l_emp.sal <> l_new_sal THEN UPDATE emp SET sal = l_new_sal WHERE empno = p_empno_in; END IF; END set_salary;

27. 2.2 Some SQL Style Examples SELECT e.job, e.deptno FROM emp e WHERE e.name = 'SCOTT' AND e.sal > 100000 SELECT e.job, e.deptno FROM emp e WHERE e.name = 'SCOTT' AND e.sal > 100000 SELECT e.JOB ,e.deptno FROM emp e WHERE e.name = 'SCOTT' AND e.sal > 100000 SELECT e.JOB , e.deptno FROM emp e WHERE e.name = 'SCOTT' AND e.sal > 100000 SELECT e.JOB, e.deptno FROM emp e WHERE e.name = 'SCOTT' AND e.sal > 100000

30. 2.5 View/Trigger Comment Block CREATE OR REPLACE TRIGGER tri_mytab_bi BEFORE INSERT ON mytab FOR EACH ROW DECLARE -- local variables here BEGIN NULL; END tri_mytab_bi /******************************************************************* Copyright YYYY by <Company Name> All Rights Reserved. <Short synopsis of trigger's purpose. Required.> <Optional design notes.> *******************************************************************/ ; /******************************************************************* Copyright YYYY by <Company Name> All Rights Reserved. <Short synopsis of trigger's purpose. Required.> <Optional design notes.> *******************************************************************/ CREATE OR REPLACE TRIGGER tri_mytab_bi BEFORE INSERT ON mytab FOR EACH ROW DECLARE -- local variables here BEGIN NULL; END tri_mytab_bi;

32. Data Types

33. Flow Control

34. Exception Handling

35. Dynamic SQL

36. Stored Objects

38. Use a function to return a constant if the “constant” value may change at times

39. Do not use public global variables, use getter/setter or parameters-passing

40. Never put all of a system’s constants in a single package.

43. Use SUBTYPE to avoid hard-coded variable length declarations.

44. Avoid using CHAR data type.

45. Never use zero-length strings to substitute NULL.

46. (CLOB, BLOB or BFILE ) vs. (LONG or LONG RAW)

47. NUMBER vs. PLS_INTEGER vs. SIMPLE_INTEGER (New in 11g, always not null)

50. Always use a FOR loop to process the complete cursor results unless you are using bulk operation

51. Always use a WHILE loop to process a loose array

52. Always use FIRST..LAST when iterating through collections with a loop

53. Always use EXIT WHEN instead of an IF statement to exit from a loop

54. Never EXIT from within any FOR loop, use LOOP or WHILE loop instead

55. Avoid hard-coded upper or lower bound values with FOR loops

58. Never assign predefined exception names to user defined exceptions

59. Avoid use of WHEN OTHERS clause in an exception section without any other specific handlers

60. Avoid use of EXCEPTION_INIT pragma for -20, NNN error (-20,999 ~ -20,000)

61. Use DBMS_UTILITY.format_error_stack instead of SQLERRM to obtain the full error message

64. Use bind variables. Do not concatenate strings unless needed to identify schema or table/view.

67. Always use forward declaration for private functions and procedures in packages.

68. Avoid standalone procedures or functions – put them in packages

69. Avoid using RETURN statements in a procedure(one way in one way out)

70. Try to use no more than one RETURN statement within a function

72. Try to use CASE rather than DECODE.

73. Always use COALESCE instead of NVL, if parameter 2 of the NVL function is a function call or a SELECT statement.

74. Always use CASE instead of NVL2 if parameter 2 or 3 of NVL2 is either a function call or a SELECT statement.

75. The NVL function always evaluates both parameters before deciding which one to use. This can be harmful if parameter 2 is either a function call or a select statement, as it will be executed regardless of whether parameter 1 contains a NULL value or not.

76. The COALESCE function does not have this drawback.

77. NVL2 is similar.

79. Thanks! Q&A

80. © 2009 Moody’s Analytics, Inc. and/or its licensors and affiliates (collectively, “MOODY’S”). All rights reserved. ALL INFORMATION CONTAINED HEREIN IS PROTECTED BY COPYRIGHT LAW AND NONE OF SUCH INFORMATION MAY BE COPIED OR OTHERWISE REPRODUCED, REPACKAGED, FURTHER TRANSMITTED, TRANSFERRED, DISSEMINATED, REDISTRIBUTED OR RESOLD, OR STORED FOR SUBSEQUENT USE FOR ANY SUCH PURPOSE, IN WHOLE OR IN PART, IN ANY FORM OR MANNER OR BY ANY MEANS WHATSOEVER, BY ANY PERSON WITHOUT MOODY’S PRIOR WRITTEN CONSENT. All information contained herein is obtained by MOODY’S from sources believed by it to be accurate and reliable. Because of the possibility of human or mechanical error as well as other factors, however, all information contained herein is provided “AS IS” without warranty of any kind. Under no circumstances shall MOODY’S have any liability to any person or entity for (a) any loss or damage in whole or in part caused by, resulting from, or relating to, any error (negligent or otherwise) or other circumstance or contingency within or outside the control of MOODY’S or any of its directors, officers, employees or agents in connection with the procurement, collection, compilation, analysis, interpretation, communication, publication or delivery of any such information, or (b) any direct, indirect, special, consequential, compensatory or incidental damages whatsoever (including without limitation, lost profits), even if MOODY’S is advised in advance of the possibility of such damages, resulting from the use of or inability to use, any such information. The ratings, financial reporting analysis, projections, and other observations, if any, constituting part of the information contained herein are, and must be construed solely as, statements of opinion and not statements of fact or recommendations to purchase, sell or hold any securities. NO WARRANTY, EXPRESS OR IMPLIED, AS TO THE ACCURACY, TIMELINESS, COMPLETENESS, MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OF ANY SUCH RATING OR OTHER OPINION OR INFORMATION IS GIVEN OR MADE BY MOODY’S IN ANY FORM OR MANNER WHATSOEVER. Each rating or other opinion must be weighed solely as one factor in any investment decision made by or on behalf of any user of the information contained herein, and each such user must accordingly make its own study and evaluation of each security and of each issuer and guarantor of, and each provider of credit support for, each security that it may consider purchasing, holding, or selling.