Decent editor?

Question

Hi there,
I'm about to take over a legacy project written in PL/SQL. It's not a very large project but some of the functions are very large, i.e. the kind of functions that would make make Godzilla look like a cute and tiny reptile. I've worked with a lot of languages over the years and I'm a proficient and experienced Java programmer but my experience with PL/SQL is almost non-existant so please forgive me if my questions are at a very basic level.
First of all, I have an immense urge to refactor the larger functions, both in order to get a feel for the language and to ease further maintenance. However, I have the following problems:
1) Currently the project is maintained in PL/SQL Developer. Being used to 21st century IDEs like Eclipse and IntelliJ IDEA, the PL/SQL Developer seems like rather shoddy and "old school". I definitely miss some refactoring support, such as the ability to easily extract code or rename functions. Also, editing code directly in the database makes it very difficult to implement version control (currently there is none at all). I suppose that a viable soultion would be to edit a local copy (under VCS control, of course) and let a build script upload the code to the database. Anyway,
a) Would this idea make sense?
b) I can't be the only one facing this problem. So, what is everyone else doing?
c) Can anyone recommend a decent PL/SQL IDE?
2) This one is more language related. I find that when I define a new function, I have to define (and, in the long run, maintain) the signature part in both the package definition and the package body. This seems like a pain, and in any case it's an unnecessary redundancy. Most of the methods that I define while refactoring are really just "private" methods of no concern to other packages. Is there any way for me to avoid having to maintain the signature in two places?
Thanks in advance :)
/Martin Olsen, Norway

Answer 1

First off, I feel your pain. Nothing worse than having to clear up someone elses mess ;-)
However i have some tips that should help you in your quest....
Firstly source control is key with PL/SQL code (as with any other language).
What our developers do is use eclipse for java/client coding but also use its built in CVS features for managing the PL/SQL files also i.e. we check our PL/SQL files in and out of our repository. Therefore managing changes made by multiple developers.
The important thing we have is the ability to build a schema from the repository by clicking a simple using a one click ANT target (using the ant view in Ecplise) which allows two developers to work on their own deveopment schemas in isolation, safe in the knowledge that they have an up to date code, and then only publish their updates once they are finished and fully tested. Needless to say there are complications sometimes but it's worked fairly well for our small-to-mid sized team.
The other advantage our schema rebuild utility allows is regular, automated testing. We regularly run (i.e. every 2 hours or so) a full rebuild and full run of all our unit test (client/java/ and pl/sql) this helps us ensure our repository code is clean. The developer can also run all tests (or a subset of tests) at any time to make sure what they have done isn't going to break something elsewhere. This is also done using the ANT from within eclipse. It's not as integrated as JUnit is but it's better than manually running all your tests.
You can either write the tests manually using the framework mentioned briefly above (utplsql) it's based on nunit (the parent to Junit) so it should be familar to a java developer. or you could use QUTE, also mentioned above.
I have to disagree with your "review" of PL/SQL developer. As user a few oracle IDEs I've found PL/SQL Developer to be the one I get on best with. And I thought I should mention that if you're on a fairly up to date version, it has a good set of refactoring features. See below for an extract from the help file (saves me typing ;-) )
The refactoring function allows you to quickly reorganize your PL/SQL code. It works on the selected code, or – if no selection is made – on the current statement. Right-clicking on a statement or selection provides the following refactoring functions in the corresponding submenu:
· Rename item
Renames the current variable, parameter, constant or program unit. Both the declaration and usage will be renamed.
· Extract procedure
If a program unit has become too large or too complex, you can make a selection and convert it to a separate procedure. All variables used within and outside of the selection will be converted to parameters. All variables used only within the selection will be moved from the current program unit to the new program unit. The selection will be replaced by a call to the new program unit.
· Extract local constant
If a certain expression should be converted to a local constant, you can select it and provide the constant name. A local constant will be created within the current subprogram, of a type that is determined from the expression. All occurrences of the expression in the current subprogram will be replaced by the constant name.
· Extract global constant
If a certain expression should be converted to a global constant, you can select it and provide the constant name. A global constant will be created within the current package, of a type that is determined from the expression. All occurrences of the expression in the current package will be replaced by the constant name.
· Replace assignment with initialization
If a local variable assignment is purely for initialization, you can move it to the declaration of the variable. You can right-click on a statement or select multiple statements.
These options are available from the context menu.
Finally, to address your finaly query, as you are a Java developer I'd suggest you treat the package specification (definition) just as you would treat an interface class in java and treat the package body like the interface implenentation. This should keep you straight till you get to grips with the language ;-)
I hope you find some of this helpful and one final tip, usually when a procedure is HUGE it can mean there is too much procedural logic going on i.e. too much PL/SQL code (loops, if statements, SQL statements) that could be reduced by using SQL a little better.
I'm not saying every big procedure is wrong just that there's a chance that if you see a lot of SQL statements, loops or IF staments there;s a good chance it can be reduced to one or two SQL statements.
good luck