Pl/sql coding rules to be followed by Oracle databases

Four simple guidelines to improve the number and quality of Pl/sql code

I've been writing Pl/sql code since 1990. That means I've written tens of thousands of of lines of software code, but I'm sure most of the code is very clumsy and difficult to maintain.

Luckily, I find it's not too late to find and follow a new way to write better code. It was last year that I had a significant improvement in the quality of my Code, which was mainly due to the fact that some simple rules had been developed and complied with as discipline.

This article provides four suggestions for novice and experienced developers of pl/sql, and if you follow any of them, your code will improve in quality. These four tips are accepted, and you may be surprised to find that you are a very good programmer, far beyond your imagination.

All the work is done alone

Few of us work in isolation; most pl/sql development work is done in relatively large institutions. But we're basically working alone in our cubicle with our own equipment. Few Pl/sql development teams perform regular code reviews or system tests.

I can't change the basic state of your development team through this article. Therefore, I carefully selected the following suggestions. The implementation of any of these is not subject to the consent of the manager. Whether your group is large or small, you don't have to let everyone in the code agree with the coding rules. You only need to follow the advice below to change the way you encode yourself:

1. Strictly follow the naming conventions as if they are your life pillars.

2. Abstain from writing sql: the less SQL you write, the better.

3. Make the operative part short: Farewell to "Spaghetti Code".

4. Find a partner: very much agree to find someone to oversee your work.

1. Follow naming conventions

If you build and strictly follow a set of naming conventions, especially for application components, you can save a lot of time.

Of course, the idea of following a naming convention is nothing new, and you may be tired of hearing it. So I'm not proposing any grand naming scheme, but giving some very specific and definite engagements and proving how useful these engagements are.

I've been designing and building a new tool for pl/sql developers in the last few months. It is named SWYG (which can be found in www.swyg.com) and can help programmers complete the generation, testing, and reuse of code. It has several unique components. I have specified a two-letter abbreviated name for each component, as follows:　　SF-Swyg的基础部件
　　SM-Swyg的元数据
　　SG-Swyg的生成程序
　　SL-Swyg的 代码库
　　ST-Swyg的单元测试

So I followed the naming convention in table 1 and used these abbreviations. What are the benefits of following these conventions? In general, if I ask for consistent naming rules, I can write code more smoothly and efficiently.

Specifically, these conventions are predictable, meaning that the SQL program I write can generate useful scripts. For example, by using the Conventions in table 1, you can generate installation scripts for all the underlying packages in SWYG. The Sql*plus script that performs these tasks is shown in Listing 1. This kind of script is useful because it means that I don't have to manually maintain the installation script. When I add another table to the SWYG scenario and generate a set of related packages, I just run my script and the updated Setup script jumps out.