Developer's Tip of the Month

From: Cam White <info_at_revealnet.com>
Date: 1997/10/20
Message-ID: <01bcddac$12612100$0373b1cd_at_Preveal2>#1/1


You are invited to join and participate in the "PL/SQL Pipeline" - a free internet forum for Oracle Developers sponsored by RevealNet. You can access the PL/SQL Pipeline by pointing your web browser to http://www.revealnet.com/plsql-pipeline/index.htm

The forum is hosted by popular Oracle author and instructor Steven Feuerstein
("Oracle PL/SQL Programming" and "Advanced Oracle PL/SQL Programming with Packages", O'Reilly & Associates). Use the forum to share technical solutions, tips and techniques. Download white papers from the "Archives". Try to solve our monthly "Puzzlers", and your name will automatically be entered into a drawing for free technical books from O'Reilly & Associates.

OCTOBER'S TIP OF THE MONTH! Most every PL/SQL developer still keeps her or his source code in operating system files. If you are a part of that majority, then here are a few tips for managing your code:

•Keep package specifications in different files from package bodies. After the initial phase of development, most changes to the package will be changes to the package body. if you keep both parts of the package in the same file, you will recompile both. Whenever you recompile the package specification, all programs that rely on the package will also have to be recompiled. But if you only change and recompile the body, no other programs are affected.

•Create all package specifications before package bodies. The package specs are the public interfaces. So if you get all the package specifications "in place" before compiling any of the bodies, you will be much less likely to run into unresolved program and element references.

•Use consistent and different file extensions for different kinds of code. Don't use ".sql" for all of your code files. I use ".sps" for Stored Package Specification and ".spb" for Stored Package Body. It is much easier to locate and differentiate your code if you take this approach early on and apply it consistently. Received on Mon Oct 20 1997 - 00:00:00 CEST

Original text of this message