Some Naming and Coding Standards
April 25, 2000
Table of Contents
Table of Contents 2
Benefits of Having Standards 3
Format of this Document 3
File naming conventions 3
Identifier naming conventions 4
Primary Identifier 5
Variable Usage Conventions 5
Cursor Declarations 6
FOR loop index 6PL/SQL table TYPE 7
Programmer-defined subtype 7
PL/SQL Record TYPE 7
Code format 8
Using Case to Aid Readability 9
Formatting Single Statements 9
Formatting Declarations 10
Formatting Multiline Statements 10
Commenting style 11
Comment As you Code 11
Explain Why - Not the How 11
Make Comments Easy to Enter and Maintain 11
Maintain Indentation 11Syntax Guidelines 11
Branching and Labels 11
Conditional Statements 12
Avoid Unstructured Exits from Loops 18
Do not use PL/SQL where you can use a SQL statement instead. 18
PL/Sql Programming Guidelines 18
Use Named Constants to Avoid Hard-coding Values 18
Convert Variables into Named Constants 19
Avoid the recycling of variables 19
Name Subtypes toSelf-document Code 19
Remove Unused Variables from Programs 20
Use %TYPE when a variable represents a column 20
Use %TYPE to standardize non-database declarations 20
Use Variables to hide complex logic 21
Building from high-level rules 22
Converting pseudo-code to PL/SQL 23
SQL Guidelines 25
Right align the reserved words 25
Don’t skimp on line seperators 25
Use sensibleabbreviations for table and column aliases 26
The first and most important thing about standards is to have them. Once you sit down and come up with a set of standards then it becomes very easy to follow them. Remember when you first learned to drive! It seemed to take up all your attention just to keep the car going straight ahead. But now you probably do not even think aboutit. Standards are the same way. Once you get used to them, they don’t even seem to exist.
The sign of a good standard is that it facilitates your work. Not come in the way of your work. To arrive at that point takes a lot of hard work. That is where PL/Solutions’ expertise comes in handy. We at PL/Solutions, led by Steven Feuerstein have spent many years culling different approaches to comeup with the following standards. Use them and be happy.
First and foremost, standards have to be simple. If there are so many rules that you always need a reference card, then you are never going to use them. On the other hand if they are too simple, you might as well not use one. So you need to strike a balance between too hard and too simple to come up with something that is just rightfor you.
Programming is very personal. It is like writing a story or a piece of music, or painting a picture. So we don’t pretend that what we are proposing here is the ultimate truth. This has worked for us. We will be happy if it works for you. Having standards is beneficial to a lot of different people.
Benefits of Having Standards
Less decisions to make
Having guidelines tofollow means that there are some decisions that you not have to make. You also do not have to justify, argue and defend every decision you make. You may not agree with every part of the standard, but you will be surprised how soon you will be comfortable with the standards.
Maintenance programming becomes easier since the code is easier to read and modify.
With standard guidelines, it is easy to set up a training program, whether it is a hands on session or a CBT. New hires can be trained in a day or two to conform to the corporate standards.
Easier to Automate
With a well-defined standard you can plug it into an automatic formatter like PL/Formatter from RevealNet and format legacy code to conform to corporate...
Lire le document complet
Veuillez vous inscrire pour avoir accès au document.