I teach a series of classes called "Achieving PL/SQL Excellence." I spend a lot of time in those classes talking about "best practices," the guidelines and techniques you should follow to write excellent PL/SQL programs. It's not enough to simply know how to write a procedure, function, or package. You need to know how to write those modules so that you are productive and so that the code is readable, efficient, and maintainable. That is a far more challenging task.
There are a couple of different options to implementing best practices:
The manual (a.k.a. "hard") way: Write or obtain a document that lists those best practices. Make sure that all developers study this guide and then set up a code review process to make sure that the standards and techniques have been followed.
The automatic way: Build or obtain a development environment that incorporates, generates, and automatically promotes the use of your best practices.
It should be pretty obvious to everyone which of these two options is preferable. Yet it is more than a matter of preference. The manual approach is also thoroughly impossible to apply with any degree of success. It requires a level of discipline and commitment from each developer that simply isn't practical. In addition, there are no tools available that allow you to do your code review in any practical fashion.
The automatic way is undeniably the way to go—but who's going to get you going? After years of developer agony, third-party ...