Three Simple Steps to Improving PL/SQL Code Quality

Transcription

1 Three Simple Steps to Improving PL/SQL Code Quality Steven Feuerstein Oracle Developer Advocate for PL/SQL Oracle Corporation Blog: stevenfeuersteinonplsql.blogspot.com YouTube: Practically Perfect PL/SQL 1

2 Resources for Oracle Database Developers Official home of SQL and PL/SQL - oracle.com/sql oracle.com/plsql SQL-PL/SQL discussion forum on OTN PL/SQL and EBR blog by Bryn Llewellyn - Oracle Learning Library - oracle.com/oll Quizzes, workouts and classes - devgym.oracle.com Ask Tom - asktom.oracle.com 'nuff said (+ new! Office Hours!) LiveSQL - livesql.oracle.com script repository and 12/7 12c database oracle-base.com - great content from Tim Hall oracle-developer.net - great content from Adrian Billington Page 2

3 Agenda Short and Sweet Why should we care? Compile-time warnings Write tiny little chunks of code Instrument your code Page 3

4 Why should we care? Pride of ownership/craft Code in the database plays a fundamental role in application Database code lives on much longer than UX/UI code Page 4

5 Compiler Features Automatic, transparent optimization of code Compile-time warnings framework to help you improve the quality and performance of your code. Conditional compilation You decide what code should be compiled/ignored! Page 5

6 Warnings help you build better code Your code compiles without errors. Great, you can run that program! But does it use the PL/SQL language optimally? PL/SQL offers a compile-time warnings feature to answer this question. Automatically informs you of ways to improve the quality or performance of your code. Available warnings are documented in the Oracle Database Error Messages document: PLS prefix = PL/SQL compiler error PLW prefix = compile-time warning Page 6

7 Enable and Disable Warnings To use compiler warnings, you must turn them on for session or for a particular program unit. By default, warnings are disabled. Can specify individual warnings or categories. SQL Developer Preferences/PL/SQL Compiler offers UI access. ALTER SESSION [ENABLE DISABLE ERROR]: [ALL SEVERE INFORMATIONAL PERFORMANCE warning_number] REM To enable all warnings in your session: ALTER SESSION SET plsql_warnings = 'enable:all'; REM If you want to enable warning message number and all warnings in REM the performance category, and treat 5005 as a "hard" compile error: ALTER PROCEDURE my_procedure SET plsql_warnings = 'enable:06002', 'enable:performance', 'ERROR:05005'; Page 7

8 Checking for Warnings The USER_ERRORS data dictionary view shows both "hard" errors and compilation warnings. Use the SHOW ERRORS command in SQL*Plus. IDEs will usually display warnings within the edit window. Or run your own query against USER_ERRORS. Page 8

9 Example: check for unreachable code There may be lines of code that could never, ever execute. SQL> CREATE OR REPLACE PROCEDURE unreachable_code IS 2 x NUMBER := 10; 3 BEGIN 4 IF x = 10 THEN 5 x := 20; 6 ELSE 7 x := 100; -- unreachable code 8 END IF; 9 END unreachable_code; 10 / SP2-0804: Procedure created with compilation warnings SQL> show err Errors for PROCEDURE UNREACHABLE_CODE: LINE/COL ERROR /7 PLW-06002: Unreachable code plw6002.sql Page 9

10 Useful warnings added in 11.1 PLW-6017: something's going to raise an error! Such as VARCHAR2(1) := 'abc'...finally! PLW-6009: OTHERS exception handler does not re-raise an exception. More feedback on impact of optimization PLW-6007: Notification that entire subprograms were removed PLW-7205: warning on mixed use of integer types Namely, SIMPLE_INTEGER mixed with PLS_INTEGER and BINARY_INTEGER PLW-7206: unnecessary assignments Lots of PRAGMA INLINE-related warnings plw*.sql files Page 10

11 The Oracle Knows: an error will occur CREATE OR REPLACE PROCEDURE plw6017 IS c VARCHAR2 (1) := 'abc'; BEGIN One big frustration I have had with compile-time warnings is that it did not flag code like you see above. What could be more basic? This (and more) is finally addressed in Oracle11g with the PLW warning. PLW-06017: an operation will raise an exception plw6017.sql Page 11

12 Treating a warning as "hard" compile error You might identify a warning that reflects such bad coding practices, that you want to ensure it never makes its way into production code. Just set the warning as an error and stop the use of that program "in its tracks." "Function does not return value" is a prime example. You never want this error to appear to users. Too embarrassing. ALTER SESSION SET PLSQL_WARNINGS='ERROR:5005' plw5005.sql Page 12

13 Conclusions - Compile-time Warnings Review the available warnings. Identify those which are of greatest importance to you. And with each new release of Oracle check for additions. Consider setting up scripts to enable different sets of warnings to match different development scenarios and to ignore those "nuisance" warnings. Or go radical: enable ALL warnings as ERRORS, and go for a 100% clean compile every single time! ALTER SESSION SET PLSQL_WARNINGS='ERROR:ALL' Page 13

14 Hope for the Best, Plan for the Worst Programmers are very optimistic too optimistic. We think we will be able to understand tomorrow the code we write today. We think users will use our apps the way they are intended. But we know that there will be problems, there will be mysteries. So it's important to be proactive. Make it easier to report, diagnose and fix problems. Consistent, encapsulated error management User-defined instrumentation (execution tracing) And make sure to provide explanations (comments) for any "out of the ordinary" code. Page 14

15 Consistent, encapsulated error management Ideally, all exception handlers log and re-raise errors in the same way. Store system and application-specific information Pass local variable and "application state" to error logger. Call built-ins to get error stack, execution stack and backtrace Avoid hard-coding of error numbers and messages Use EXCEPTION_INIT to give names to errors. Build your own (see errpkg for very simple example) or use something like logger, an open source logging and debugging framework Page 15 errpkg.pkg

16 User-defined instrumentation (execution tracing) Use Oracle Trace to obtain system tracing. But that's usually not enough. Trace additional, application-specific information from code while running. Make it easy to toggle on/off while application is running. Critical for production (don't comment it out after you are done testing). DBMS_OUTPUT.PUT_LINE is the "default" tracing mechanism and should never appear in your application code. You expose the trace/display mechanism. Too many drawbacks, too little flexibility. Page 16

17 Alternative Tracing Mechanisms Trace packages in demo.zip include: sf_trace: my latest, simple and sufficient tracer watch.pkg: "watch" the action, ability to direct trace information to a variety of targets. logger: open source logging and debugging framework DBMS_APPLICATION_INFO Writes to V$ views, good for long-running operations sf_trace*.* watch.pkg dbms_application_info_demo.sql Page 17

18 Write tiny little chunks of code Spaghetti code is the bane of a programmer's existence. It is impossible to understand and therefore debug or maintain code that has long, twisted executable sections. Fortunately, it is really easy to make spaghetti code a thing of the past. Organize your code so that the executable section of any block has no more than fifty lines of code. Page 18 intab_dbms_sql.sp local_module.sql cc_smartargs.sql logger_init_before_after.sql

19 Tiny executable sections = Readable code Follow this one suggestion no special tools required and you can instantly transform the quality and readability of your code. Some tips for implementing tiny executable sections: Hide complex expressions behind constants and functions. Use top-down design (decompose overwhelming challenges into smaller, more manageable tasks). Use Extract Procedure refactoring in your IDE. Evaluate each subprogram for correct scope: is it useful to others? Page 19

20 It's Easy to Write High Quality Code Wait. Really? I suppose it's actually easier (in the short term) to write really bad code. But there are also steps you can take that are not too awfully difficult, which can have a dramatic positive impact on code quality. 1. Fully leverage the PL/SQL compiler, especially the warnings. 2. Hope for the best, plan for worst: instrument your code. 3. Write tiny chunks of code: modularize, especially with nested subprograms. Page 20

21 21