|
| 1 | +# Introduction |
| 2 | + |
| 3 | +This document describes rules and recommendations for developing applications using the PL/SQL & SQL Language. |
| 4 | + |
| 5 | +## Scope |
| 6 | + |
| 7 | +This document applies to the PL/SQL and SQL language as used within ORACLE databases and tools, which access ORACLE databases. |
| 8 | + |
| 9 | +## Document Conventions |
| 10 | + |
| 11 | +SQALE (Software Quality Assessment based on Lifecycle Expectations) is a method to support the evaluation of a software application source code. It is a generic method, independent of the language and source code analysis tools. |
| 12 | + |
| 13 | +### SQALE characteristics and subcharacteristics |
| 14 | + |
| 15 | +Characteristic | Description and Subcharacteristics |
| 16 | +-------------- | ---------------------------------- |
| 17 | +Changeability | The capability of the software product to enable a specified modification to be implemented.<ul><li>Architecture related changeability</li><li>Logic related changeability</li><li>Data related changeability</li><ul> |
| 18 | +Efficiency | The capability of the software product to provide appropriate performance, relative to the amount of resources used, under stated conditions.<ul><li>Memory use</li><li>Processor use</li><li>Network use</li></ul> |
| 19 | +Maintainability | The capability of the software product to be modified. Modifications may include corrections, improvements or adaptation of the software to changes in environment, and in requirements and functional specifications.<ul><li>Understandability</li><li>Readability</li></ul> |
| 20 | +Portability | The capability of the software product to be transferred from one environment to another.<ul><li>Compiler related portability</li><li>Hardware related portability</li><li>Language related portability</li><li>OS related portability</li><li>Software related portability</li><li>Time zone related portability.</li></ul> |
| 21 | +Reliability | The capability of the software product to maintain a specified level of performance when used under specified conditions.<ul><li>Architecture related reliability</li><li>Data related reliability</li><li>Exception handling</li><li>Fault tolerance</li><li>Instruction related reliability</li><li>Logic related reliability</li><li>Resource related reliability</li><li>Synchronization related reliability</li><li>Unit tests coverage.</li></ul> |
| 22 | +Reusability | The capability of the software product to be reused within the development process.<ul><li>Modularity</li><li>Transportability.</li></ul> |
| 23 | +Security | The capability of the software product to protect information and data so that unauthorized persons or systems cannot read or modify them and authorized persons or systems are not denied access to them.<ul><li>API abuse</li><li>Errors (e.g. leaving a system in a vulnerable state)</li><li>Input validatation and representation</li><li>Security features.</li></ul> |
| 24 | +Testability | The capability of the software product to enable modified software to be validated.<ul><li>Integration level testability</li><li>Unit level testability.</li></ul> |
| 25 | + |
| 26 | +### Severity of the rule |
| 27 | + |
| 28 | +!!! bug "Blocker" |
| 29 | + Will or may result in a bug. |
| 30 | + |
| 31 | +!!! danger "Critical" |
| 32 | + Will have a high/direct impact on the maintenance cost. |
| 33 | + |
| 34 | +!!! warning "Major" |
| 35 | + Will have a medium/potential impact on the maintenance cost. |
| 36 | + |
| 37 | +!!! tip "Minor" |
| 38 | + Will have a low impact on the maintenance cost. |
| 39 | + |
| 40 | +!!! info "Info" |
| 41 | + Very low impact; it is just a remediation cost report. |
| 42 | + |
| 43 | +### Keywords used |
| 44 | + |
| 45 | +Keyword | Meaning |
| 46 | +----------- | ------- |
| 47 | +Always | Emphasizes this rule must be enforced. |
| 48 | +Never | Emphasizes this action must not happen. |
| 49 | +Avoid | Emphasizes that the action should be prevented, but some exceptions may exist. |
| 50 | +Try | Emphasizes that the rule should be attempted whenever possible and appropriate. |
| 51 | +Example | Precedes text used to illustrate a rule or a recommendation. |
| 52 | +Reason | Explains the thoughts and purpose behind a rule or a recommendation. |
| 53 | +Restriction | Describes the circumstances to be fulfilled to make use of a rule. |
| 54 | + |
| 55 | +### Why are standards important |
| 56 | + |
| 57 | +For a machine executing a program, code formatting is of no importance. However, for the human eye, well-formatted code is much easier to read. Modern tools can help to implement format and coding rules. |
| 58 | + |
| 59 | +Implementing formatting and coding standards has the following advantages for PL/SQL development: |
| 60 | + |
| 61 | +* Well-formatted code is easier to read, analyze and maintain (not only for the author but also for other developers). |
| 62 | +* The developers do not have to define their own guidelines - it is already defined. |
| 63 | +* The code has a structure that makes it easier to avoid making errors. |
| 64 | +* The code is more efficient concerning performance and organization of the whole application. |
| 65 | +* The code is more modular and thus easier to use for other applications. |
| 66 | + |
| 67 | +This document only defines possible standards. These standards are not written in stone, but are meant as guidelines. If standards already exist, and they are different from those in this document, it makes no sense to change them. |
| 68 | + |
0 commit comments