Maintainability

Code Rules in Maintainability category

Category Severity Name Description
Maintainability Critical %TYPE and %ROWTYPE should not be used in package specification

The %TYPE and %ROWTYPE should not be used in package specification as they are not allowed in the package specification. These two attributes are used to declare a variable or a column of a table. They are used to store the data type of the variable or the column. The %TYPE attribute is used to store the data type of a variable and the %ROWTYPE attribute is used to store the data type of a column of a table. Using these two attributes in the package specification will result in an error.

Maintainability Critical A primary key should be specified during table creation

When creating a table in PL/SQL, it is important to specify a primary key. A primary key is a column or set of columns that uniquely identifies each row in a table. By specifying a primary key, it ensures that each row in the table is uniquely identified and can be easily referenced. This also helps to ensure data integrity, as it prevents duplicate entries from being created in the table. Additionally, it can help to improve query performance, as the primary key can be used to quickly locate a specific row in the table. Therefore, it is best practice to always specify a primary key when creating a table in PL/SQL.

Maintainability Minor An ORDER BY direction should be specified explicitly

The rule "An ORDER BY direction should be specified explicitly" means that when using an ORDER BY clause in a PL/SQL statement, the direction of the ordering (ascending or descending) should be explicitly stated. This helps to ensure that the results are consistent and predictable. Without explicitly specifying the direction, the results may vary depending on the database engine being used.

Maintainability Critical Block labels should appear on the same lines as END

The rule "Block labels should appear on the same lines as END" states that when writing PL/SQL code, the label of a block should be placed on the same line as the END statement that marks the end of the block. This helps to make the code more readable and easier to understand. It also makes it easier to identify the start and end of each block, which can be useful when debugging or troubleshooting.

Maintainability Critical Block start and end labels should match

The rule "Block start and end labels should match" states that when writing PL/SQL code, the labels used to mark the start and end of a block of code should be the same. This helps ensure that the code is properly structured and that all of the code within a block is executed as expected. It also helps to make the code easier to read and understand.

Maintainability Critical Blocks containing EXECUTE IMMEDIATE should trap all exceptions

The rule "Blocks containing EXECUTE IMMEDIATE should trap all exceptions" states that when using the EXECUTE IMMEDIATE command in a PL/SQL block, all exceptions should be trapped. This means that any errors that occur during the execution of the command should be handled by the PL/SQL block. This is done by using the EXCEPTION clause, which allows the programmer to define how the errors should be handled. This ensures that the program can continue to execute even if an error occurs. This is important for ensuring that the program does not crash or produce unexpected results.

Maintainability Minor Boolean checks should not be inverted

The rule "Boolean checks should not be inverted" states that Boolean checks should not be written in a way that reverses the logic of the check. This means that the code should not use "not" or "!" to invert the result of a Boolean check. Instead, the code should be written in a way that directly expresses the logic of the check.

Maintainability Minor Boolean literals should not be redundant

The "Boolean literals should not be redundant" rule states that when writing PL/SQL code, Boolean literals should not be used redundantly. This means that if a Boolean literal is already established, it should not be repeated. This rule is important for writing efficient and effective code, as repeating Boolean literals can lead to confusion and errors.

Maintainability Critical CASE expressions should end with ELSE clauses

The CASE expression rule states that all CASE expressions should end with an ELSE clause. This clause is used to provide a default value when none of the conditions in the CASE expression are met. This ensures that the CASE expression will always return a value, even if none of the conditions are met. It also helps to make the code more readable and maintainable by making it clear what the default value should be.

Maintainability Minor CASE should be used for sequences of simple tests The CASE statement should be used for sequences of simple tests in PL/SQL code. This statement is used to evaluate a set of conditions and execute a block of code depending on the result of the evaluation. The CASE statement can be used to replace multiple IF statements, making the code more concise and easier to read.
Maintainability Major CASE should be used rather than DECODE

The CASE statement in PL/SQL is used to select one of several blocks of statements based on a given condition. It is similar to the DECODE statement, but it is more powerful and more flexible. The CASE statement can be used to replace multiple DECODE statements, making the code more readable and efficient. The CASE statement can also be used to evaluate multiple conditions and execute different statements based on the result.

Maintainability Major CASE structures should not have too many WHEN clauses

The rule "CASE structures should not have too many WHEN clauses" states that when using a CASE structure in PL/SQL code, it is best practice to limit the number of WHEN clauses used. This is because too many WHEN clauses can lead to code that is difficult to read and maintain, and can also lead to performance issues. It is recommended to use IF-THEN-ELSE statements instead of multiple WHEN clauses when possible.

Maintainability Minor Code elements must not be unused

The Pl_Sql code rule "Code elements must not be unused" states that all code elements must be used in the code, and any code elements that are not used must be removed. This rule helps to ensure that the code is efficient, organized, and free of unnecessary clutter. Unused code elements can lead to confusion and can make the code harder to maintain. By removing unused code elements, the code will be easier to read and understand, and it will be easier to identify any potential errors.

Maintainability Major Collapsible if statements should be merged

The "Collapsible if statements should be merged" rule states that when two or more if statements can be logically combined into one, they should be merged into a single statement. This helps to reduce the complexity of the code and improve readability. By merging multiple if statements, the code becomes more concise and easier to understand. Additionally, it can help to reduce the number of lines of code and make debugging and maintenance easier.

Maintainability Major Column aliases should be defined using AS

The rule "Column aliases should be defined using AS" in PL/SQL code states that when creating a column alias, the keyword "AS" should be used. This is done to make the code easier to read and understand. For example, if you wanted to create an alias for a column called "FirstName" in a table called "Employees", you would write the following code:

SELECT FirstName AS "Employee Name" FROM Employees;

By using the keyword "AS", it is easier to distinguish between the original column name and the alias. This rule is important to follow when writing PL/SQL code, as it helps to make the code more readable and understandable.

Maintainability Major Column names should be used in a SQL ORDER BY clause

The Pl_Sql code rule that "Column names should be used in a SQL ORDER BY clause" states that when writing a SQL query, the column names should be explicitly specified in the ORDER BY clause. This ensures that the query is written correctly and that the results are ordered in the desired way. This rule also helps to avoid any unexpected behavior when the query is executed.

Maintainability Major Columns should be aliased

The "Columns should be aliased" rule in PL/SQL code states that when selecting multiple columns from a table, each column should be given an alias. This is done to make the code easier to read and understand. By assigning an alias to each column, it is easier to identify which column is being referenced in the code. This also helps to avoid confusion when referencing columns in other parts of the code. Additionally, it is best practice to use meaningful aliases that accurately describe the column.

Maintainability Major Columns to be read with a SELECT statement should be clearly defined

The "Columns to be read with a SELECT statement should be clearly defined" rule states that when writing a SELECT statement in PL/SQL, the columns that will be read from the database should be explicitly stated. This ensures that the query is only retrieving the necessary data, and that the results of the query are predictable. It also helps to prevent errors and improve the performance of the query.

Maintainability Minor Comments should not be located at the end of lines of code

The Pl/SQL code rule "Comments should not be located at the end of lines of code" means that comments should not be placed at the end of a line of code, as this can lead to confusion and errors. Comments should be placed on their own line, or at the beginning of a line of code, so that they are clearly visible and not mistaken for part of the code. This helps to ensure that the code is well-documented and easy to understand.

Maintainability Minor Comments should not be nested

The rule "Comments should not be nested" means that comments should not be placed within other comments. This is because comments are used to explain code and make it easier to read, and when they are nested they can become confusing and difficult to read. It is best practice to avoid nesting comments and instead use separate comments for each section of code.

Maintainability Major Compound triggers should define at least two triggers

Compound triggers are a type of trigger in PL/SQL that allow multiple triggers to be defined for a single table. The rule states that compound triggers should define at least two triggers. This means that when a compound trigger is created, it must include two or more triggers that will be triggered when a certain event occurs. This allows for more complex logic to be implemented when a certain event occurs, such as updating multiple tables or performing multiple operations. Compound triggers can be used to simplify and streamline the code needed to perform complex operations when a certain event occurs.

Maintainability Minor Constraint names should comply with a naming convention

The rule "Constraint names should comply with a naming convention" states that all constraints in a PL/SQL code should have names that follow a specific naming convention. This ensures that the names of the constraints are consistent and easily identifiable. The naming convention should be agreed upon by the development team and should be documented in the project documentation. This will help to ensure that the names of the constraints are easily recognizable and understood by all members of the development team.

Maintainability Critical CREATE OR REPLACE should be used instead of CREATE

The CREATE OR REPLACE rule states that when creating or modifying an existing PL/SQL object, the CREATE OR REPLACE statement should be used instead of the CREATE statement. This ensures that any existing object is replaced with the new version, rather than creating a duplicate object with the same name. This rule also applies to other types of objects, such as views, triggers, and stored procedures. By using the CREATE OR REPLACE statement, developers can ensure that their code is always up-to-date and that any existing objects are not duplicated.

Maintainability Major CREATE_TIMER should not be used

The CREATE_TIMER code rule states that the CREATE_TIMER command should not be used. This command is used to create a timer in a PL/SQL block, which is an action that can cause performance issues and should be avoided. Instead, the DBMS_SCHEDULER package should be used to create and manage timers.

Maintainability Major CROSS JOIN queries should not be used

The rule CROSS JOIN queries should not be used is a rule of thumb for PL/SQL code. It means that when writing a query, one should avoid using the CROSS JOIN operator. This operator is used to combine every row from one table with every row from another table, resulting in a Cartesian product. This can lead to a large number of unnecessary rows being returned, which can lead to performance issues. It is generally better to use other operators such as INNER JOIN or LEFT JOIN, which can be used to limit the number of rows returned.

Maintainability Minor Cursor parameters should follow a naming convention

The Pl_Sql code rule "Cursor parameters should follow a naming convention" states that all cursor parameters should be named in a consistent manner. This helps to ensure that the code is easier to read and understand. For example, all cursor parameters should be prefixed with "cur_" to indicate that they are cursor parameters. This helps to differentiate them from other variables and makes the code more readable. Additionally, all cursor parameters should be named in a consistent manner, such as using camelCase or underscores. This helps to make the code more organized and easier to read. Following this rule will help to ensure that the code is more maintainable and easier to debug.

Maintainability Minor cursor%NOTFOUND should be used instead of NOT cursor%FOUND The PL/SQL code rule "cursor%NOTFOUND should be used instead of NOT cursor%FOUND" states that when checking if a cursor has returned any rows, the cursor%NOTFOUND attribute should be used instead of the NOT cursor%FOUND attribute. This is because the NOT cursor%FOUND attribute can return an unexpected result if the cursor has returned no rows. Using the cursor%NOTFOUND attribute will ensure that the correct result is returned.
Maintainability Minor Cursors should follow a naming convention

The rule "Cursors should follow a naming convention" states that all cursors used in PL/SQL code should be named in a consistent and logical manner. This helps to ensure that the code is easy to read and understand, and that any changes or additions to the code can be quickly identified. A good naming convention for cursors should include the purpose of the cursor, the type of data it is handling, and any other relevant information. For example, a cursor that is used to retrieve data from a table could be named "cur_table_data".

Maintainability Critical DBMS_OUTPUT.PUT_LINE should not be used

The DBMS_OUTPUT.PUT_LINE should not be used rule states that the DBMS_OUTPUT.PUT_LINE command should not be used in PL/SQL code. This command is used to display output from PL/SQL code, but it is not recommended for production code due to its limited capabilities and lack of scalability. Instead, it is recommended to use other methods such as writing to a log file or displaying output in a web page.

Maintainability Minor DBMS_UTILITY.FORMAT_ERROR_STACK and FORMAT_ERROR_BACKTRACE should be used together

The DBMS_UTILITY.FORMAT_ERROR_STACK and FORMAT_ERROR_BACKTRACE should be used together in order to get a comprehensive view of the error stack and backtrace. The FORMAT_ERROR_STACK function will return the error stack as a single string, while the FORMAT_ERROR_BACKTRACE function will return the backtrace as a single string. When used together, these functions will provide a comprehensive view of the error stack and backtrace, allowing for easier debugging and troubleshooting.

Maintainability Major Dead stores should be removed

The rule "Dead stores should be removed" states that any variables that are assigned a value but never used should be removed from the PL/SQL code. This is because any variables that are never used waste memory and can slow down the code execution. Removing these variables can help to improve the performance of the code. Additionally, it can help to reduce the complexity of the code and make it easier to read and understand.

Maintainability Major Deprecated LONG and LONG RAW datatypes should no longer be used

The rule "Deprecated LONG and LONG RAW datatypes should no longer be used" states that the LONG and LONG RAW datatypes, which are deprecated, should not be used in PL/SQL code. These datatypes have been superseded by other datatypes, such as CLOB and BLOB, which are more efficient and provide better performance. Therefore, it is recommended that developers use the newer datatypes instead of the deprecated LONG and LONG RAW datatypes.

Maintainability Major END statements of labeled blocks should be labeled

The "END statements of labeled blocks should be labeled" rule states that any END statement used to close a labeled block should be labeled with the same label used to open the block. This helps to ensure that the code is properly structured and that the programmer can easily identify the start and end of the labeled block. Labeling the END statement also helps to reduce the chances of errors in the code, as it makes it easier to identify the start and end of the block.

Maintainability Major END statements of labeled loops should be labeled

The END statements of labeled loops should be labeled rule states that when a loop is labeled, the corresponding END statement should also be labeled. This is important for readability and maintainability of the code, as it makes it easier to identify which loop a particular END statement belongs to. It also helps to ensure that the loop is properly closed, as any errors in the loop's structure can be easily identified. This rule is applicable to all types of loops, including FOR, WHILE, and REPEAT loops.

Maintainability Minor EXCEPTION WHEN ... THEN clauses should do more than RAISE The EXCEPTION WHEN ... THEN clauses should do more than just RAISE an exception. These clauses should also include additional logic to handle the exception, such as logging the error, rolling back the transaction, or performing other corrective actions. This helps to ensure that the application is robust and can handle unexpected errors.
Maintainability Critical EXCEPTION_INIT -20,NNN calls should be centralized

The EXCEPTION_INIT -20,NNN rule states that all calls to the -20,NNN exception should be centralized in one location. This means that all code that calls the -20,NNN exception should be placed in one specific area of the code, such as a single procedure or function. This helps to ensure that all code that calls the -20,NNN exception is consistent and that any changes to the exception are made in one place. This also helps to reduce the amount of duplicate code that is written, as the same code can be used for all calls to the -20,NNN exception. By centralizing the calls to the -20,NNN exception, the code is easier to maintain and debug.

Maintainability Minor Exceptions should follow a naming convention

The rule "Exceptions should follow a naming convention" states that all exceptions should be named in a consistent and logical manner. This helps to make the code easier to read and understand, and helps to prevent errors due to inconsistent naming. A naming convention should be established for exceptions, and all exceptions should follow this convention. This will help to ensure that all exceptions are named in a consistent and logical manner, and that they are easy to understand and debug.

Maintainability Major EXECUTE IMMEDIATE should be used instead of DBMS_SQL procedure calls

The EXECUTE IMMEDIATE should be used instead of DBMS_SQL procedure calls rule states that when executing dynamic SQL statements, the EXECUTE IMMEDIATE statement should be used instead of the DBMS_SQL package. EXECUTE IMMEDIATE is a PL/SQL statement that can be used to execute dynamic SQL statements. It is more efficient than the DBMS_SQL package, which requires more code and is less secure. This rule helps to ensure that dynamic SQL statements are executed in a secure and efficient manner.

Maintainability Minor EXIT should not be used in loops

The EXIT statement should not be used in loops in PL/SQL code. This is because the EXIT statement immediately exits the loop, which can lead to unexpected results. Instead, the loop should be ended by using the EXIT WHEN condition, which will exit the loop when the condition is met. This allows for more control over the loop and ensures that the loop will end when expected.

Maintainability Major EXIT WHEN should be used rather than IF ... THEN EXIT; END IF

The EXIT WHEN code rule states that the EXIT statement should be used instead of IF ... THEN EXIT; END IF when exiting a loop. This is because the EXIT WHEN statement is more concise and easier to read than the IF ... THEN EXIT; END IF syntax. Additionally, the EXIT WHEN statement is more efficient as it does not require the PL/SQL engine to evaluate the condition before exiting the loop.

Maintainability Major Features deprecated in Oracle 12 should not be used

The rule "Features deprecated in Oracle 12 should not be used" means that any features that have been deprecated (or removed) in Oracle 12 should not be used in PL/SQL code. This includes any features that have been removed from Oracle 12 or any features that have been marked as deprecated, which means they may be removed in a future version. This rule is important to follow as deprecated features may not work correctly in newer versions of Oracle, and may cause unexpected errors or performance issues.

Maintainability Major FETCH ... BULK COLLECT INTO should be used

The FETCH ... BULK COLLECT INTO rule states that when retrieving data from a database, the FETCH statement should be used in conjunction with the BULK COLLECT INTO clause. This allows for the retrieval of multiple rows of data in a single operation, which can improve performance and reduce the amount of coding needed. The BULK COLLECT INTO clause allows for the retrieval of data into a collection of records, which can then be looped through and processed. This rule is especially useful when dealing with large datasets, as it can significantly reduce the amount of time needed to process the data.

Maintainability Major Files should not have too many lines of code

The Pl_Sql code rule that "Files should not have too many lines of code" is an important rule to follow when writing code. This rule helps to ensure that code is easy to read and understand, as well as maintain and debug. Too many lines of code can make it difficult to find and fix errors, as well as make the code more difficult to read. This rule encourages developers to break up their code into smaller, more manageable chunks, which can make it easier to read and debug.

Maintainability Major FOR loop end conditions should not be hard - coded

The rule "FOR loop end conditions should not be hard-coded" means that the end conditions for a FOR loop should not be explicitly stated in the code. Instead, the end conditions should be determined by the data or variables that are being used in the loop. This ensures that the loop will always terminate when the conditions are met, regardless of the data or variables used. This also makes the code more flexible and easier to maintain.

Maintainability Major FORALL should be used

The FORALL statement in PL/SQL is used to execute a set of DML statements (INSERT, UPDATE, DELETE) on a collection of data. It is much more efficient than using a loop to execute the same set of DML statements on each element of the collection. The FORALL statement is used to improve the performance of a PL/SQL block by reducing the number of context switches between the PL/SQL engine and the SQL engine.

When using the FORALL statement, it is important to remember that the same DML statement is executed on all elements of the collection. This means that the same set of values is used for each element of the collection, and that the same set of conditions is applied to each element. This can be a great advantage when dealing with large collections of data, as it reduces the amount of code required to process the data.

Therefore, the rule for using the FORALL statement is to use it whenever possible to improve the performance of a PL/SQL block. It is especially useful when dealing with large collections of data, as it reduces the amount of code required to process the data.

Maintainability Major FULL OUTER JOINS should be used with caution

The rule "FULL OUTER JOINS should be used with caution" in PL/SQL code means that when using a FULL OUTER JOIN, one should be aware of potential performance issues and other complications. FULL OUTER JOINS are used to combine the results of two or more tables, but they can be computationally expensive and can produce unexpected results if not used correctly. Therefore, it is important to understand the implications of using a FULL OUTER JOIN and to use it only when necessary.

Maintainability Major Function and procedure names should comply with a naming convention

This rule states that all function and procedure names should follow a specific naming convention. This naming convention should be consistent and easy to understand, and should include information about the purpose of the function or procedure. This will help to ensure that all functions and procedures are easily identifiable and can be quickly located. Additionally, this will help to reduce the chances of naming conflicts between different functions and procedures.

Maintainability Major Function and procedure parameters should comply with a naming convention

The rule "Function and procedure parameters should comply with a naming convention" states that all parameters used in functions and procedures should be named according to a specific convention. This helps to make the code more readable and easier to understand. It also helps to avoid naming conflicts between parameters and other objects in the database. The naming convention should be consistent across all functions and procedures in the database. This ensures that all parameters are easily identifiable and that the code is more maintainable.

Maintainability Major Functions and procedures should not have too many parameters

The rule "Functions and procedures should not have too many parameters" is an important one to follow when writing PL/SQL code. Having too many parameters can make the code difficult to read and maintain, and can lead to errors. It is best to limit the number of parameters to only the ones that are absolutely necessary. Additionally, it is important to ensure that all parameters are properly documented so that other developers can understand their purpose and use. Finally, it is important to ensure that all parameters are properly validated to ensure that the code is secure and reliable. Following these guidelines will help ensure that your PL/SQL code is well-structured and maintainable.

Maintainability Major FUNCTIONS should not have OUT parameters

The rule that "FUNCTIONS should not have OUT parameters" means that functions should not have parameters that are used to send data out of the function. This is because functions are used to return a single value, and OUT parameters are used to send multiple values. If a function is used to return multiple values, it should be written as a procedure instead. This rule helps to ensure that functions are used for their intended purpose and that procedures are used for more complex operations.

Maintainability Critical Global public variables should not be defined

The rule "Global public variables should not be defined" states that global variables should not be declared in PL/SQL code. Global variables are variables that are accessible to all parts of the code, and can be changed by any part of the code. This can lead to unexpected behavior and can make it difficult to debug and maintain code. Therefore, it is best practice to avoid using global public variables in PL/SQL code.

Maintainability Critical GOTO should not be used to jump backwards

The Pl_Sql code rule "GOTO should not be used to jump backwards" states that the GOTO statement should not be used to jump to a previous line of code. This is because it can lead to code that is difficult to read and maintain, and can cause unexpected results. Instead, other control flow statements such as IF-THEN-ELSE, WHILE, and FOR should be used to control the flow of the program.

Maintainability Major GOTO should not be used within loops

The GOTO statement should not be used within loops in PL/SQL code. This is because it can cause unexpected behavior and can make the code difficult to read and maintain. Instead, use the EXIT statement to exit the loop, or use the CONTINUE statement to skip the rest of the loop and continue with the next iteration. This will help to ensure that the code is more readable and maintainable.

Maintainability Major GOTO statements should not be used

The GOTO statements should not be used rule in PL/SQL code states that the GOTO statement should not be used to control the flow of a program. This statement can lead to code that is difficult to read and maintain, and can cause unexpected results. Instead, PL/SQL code should use IF-THEN-ELSE, CASE, and LOOP statements to control the flow of a program.

Maintainability Major GROUP BY should not be used in SQL SELECT statements

The rule "GROUP BY should not be used in SQL SELECT statements" states that the GROUP BY clause should not be used when writing SQL SELECT statements. This rule is applicable to all SQL dialects, including PL/SQL. The GROUP BY clause is used to group rows into sets of summary rows by values of columns or expressions. When used in SELECT statements, the GROUP BY clause can lead to unexpected results and should be avoided. Instead, the ORDER BY clause should be used to sort the results of the query.

Maintainability Minor Identifiers should be written in lower case

The PL/SQL code rule "Identifiers should be written in lower case" states that all identifiers (such as variable names, procedure names, and table names) should be written using only lower case letters. This rule is important for readability and consistency, as well as to avoid potential conflicts with other identifiers. Additionally, this rule helps to ensure that code is compatible with different databases and platforms.

Maintainability Major IF statements should not be nested too deeply

The rule "IF statements should not be nested too deeply" in PL/SQL code means that when writing code, the programmer should avoid nesting multiple IF statements within each other. This is because deep nesting of IF statements can make the code difficult to read and understand, and can also lead to unexpected results. It is generally recommended that IF statements should not be nested more than three levels deep.

Maintainability Critical IF...ELSEIF constructs should end with ELSE clauses

The IF...ELSEIF code construct should always end with an ELSE clause. This ensures that all possible conditions are accounted for and that the code will execute properly. Without an ELSE clause, the code will not execute correctly if none of the IF or ELSEIF conditions are met. An ELSE clause provides a default action if none of the other conditions are met. This helps to ensure that the code is robust and can handle any situation.

Maintainability Major In labeled loops EXIT should exit the label

The Pl/SQL code rule "In labeled loops EXIT should exit the label" states that when using labeled loops, the EXIT statement should be used to exit the loop with the specified label. This ensures that the loop is exited at the correct point, and that any code after the loop is not executed. This rule helps to ensure that the code is written correctly and that the program runs as expected.

Maintainability Critical INSERT statements should explicitly list the columns to be set

The rule "INSERT statements should explicitly list the columns to be set" states that when using an INSERT statement in PL/SQL, the columns that will be set should be explicitly listed. This helps to ensure that the data is being inserted into the correct columns and that the data is valid for the column type. It also helps to avoid any potential errors that may occur when inserting data into the wrong column. Additionally, explicitly listing the columns to be set can help to improve the readability and maintainability of the code.

Maintainability Minor Jump statements should not be redundant

The rule "Jump statements should not be redundant" states that when writing PL/SQL code, unnecessary jump statements should be avoided. Jump statements are used to transfer control from one part of the code to another, and when they are redundant, they can cause confusion and make the code harder to read and understand. Therefore, it is important to ensure that all jump statements used in PL/SQL code are necessary and relevant to the code's purpose.

Maintainability Major Labels redefined in inner scopes

The "Labels redefined in inner scopes" rule in PL/SQL states that labels defined in an outer scope cannot be redefined in an inner scope. This means that if a label is defined in an outer scope, it cannot be used again in an inner scope. This rule is important to ensure that labels are used consistently throughout a PL/SQL program. It also helps to avoid confusion when debugging and troubleshooting code.

Maintainability Major Large item lists should not be used with IN clauses

The rule "Large item lists should not be used with IN clauses" in PL/SQL code states that when using the IN clause in a SQL statement, it is best to avoid using large item lists as this can lead to performance issues. This is because the IN clause will cause the database to scan through the entire list of items, which can be time consuming if the list is large. It is better to use other clauses such as EXISTS or JOIN to achieve the same result.

Maintainability Critical LIKE clauses should not be used without wildcards

The rule "LIKE clauses should not be used without wildcards" in PL/SQL code means that when using the LIKE operator, it should always be accompanied by a wildcard character. Wildcard characters are used to create patterns in strings and can be used in conjunction with the LIKE operator to search for strings that match the pattern. For example, if you wanted to search for all strings that start with the letter "A", you would use the LIKE operator with the wildcard character "%A". Without the wildcard character, the LIKE operator would only search for strings that are exactly "A".

Maintainability Major LIKE clauses should not start with wildcard characters

The rule "LIKE clauses should not start with wildcard characters" in PL/SQL code states that when using the LIKE operator in a query, the search pattern should not begin with a wildcard character. This is because starting a LIKE clause with a wildcard character can cause the query to take a long time to execute as the database engine must search through all possible matches before returning the result. Additionally, starting a LIKE clause with a wildcard character can lead to incorrect results if the search pattern is not well defined. Therefore, it is best practice to avoid beginning LIKE clauses with wildcard characters in PL/SQL code.

Maintainability Minor Lines in a multiline comment should start with *

The rule "Lines in a multiline comment should start with *" states that when writing a multiline comment in PL/SQL, each line should begin with an asterisk (*). This is a common convention for multiline comments in programming languages, and helps to make the code more readable and easier to understand.

Maintainability Minor Lines should not be too long

The Pl/SQL code rule "Lines should not be too long" means that code should be written in a way that each line does not exceed a certain length. This helps to make the code more readable and easier to debug. It also helps to keep the code organized and maintainable. Generally, lines should not exceed 80 characters in length, although this can vary depending on the coding style.

Maintainability Critical Lines should not end with trailing whitespaces

The Pl/SQL code rule "Lines should not end with trailing whitespaces" states that each line of code should not contain any unnecessary whitespace characters at the end. This helps to ensure that the code is properly formatted and easier to read. Additionally, it can help to prevent errors from occurring due to unexpected whitespace characters.

Maintainability Critical LOOP ... END LOOP; constructs should be avoided

The rule "LOOP ... END LOOP; constructs should be avoided" in PL/SQL code states that loops should not be used in code. Instead, other methods such as cursors should be used to iterate through data. Loops can be inefficient and can lead to performance issues. Additionally, they can be difficult to debug and maintain. Therefore, it is best to avoid using loops in PL/SQL code.

Maintainability Critical Loop start and end labels should match

The rule "Loop start and end labels should match" states that when writing a PL/SQL code block that contains a loop, the labels used to denote the start and end of the loop should be the same. This is important to ensure that the loop is executed correctly and that the code runs as expected. By using the same label for the start and end of the loop, it will be easier to identify the start and end points of the loop and to debug any issues that may arise.

Maintainability Major Magic numbers should not be used

The "Magic numbers should not be used" rule in PL/SQL code states that hard-coded numeric values should not be used in code. Instead, constants should be used to represent the numeric values, so that the code is more readable and maintainable. This makes it easier to understand the code and to modify it if needed.

Maintainability Minor Methods must not be empty

The Pl_Sql code rule "Methods must not be empty" requires that all methods must contain executable code and must not be left empty. This rule ensures that all methods are properly implemented and that no code is left out or forgotten. It also helps to ensure that all methods are properly tested and that any errors or bugs are identified and fixed before the code is released. This rule helps to ensure that code is well-structured, efficient, and maintainable.

Maintainability Minor Naming conventions must be applied

The rule of "Naming conventions must be applied" in PL/SQL code means that all identifiers used in the code must follow a specific naming convention. This includes variables, constants, procedures, functions, packages, and other objects. The naming convention should be consistent across all code, and should be chosen to make the code easier to read and understand. For example, variables might be named using camel case, with the first letter of each word capitalized, and constants might be named using all uppercase letters. Following a naming convention makes it easier to read and understand the code, and helps to prevent errors.

Maintainability Major Native SQL joins should be used

The rule "Native SQL joins should be used" states that when writing PL/SQL code, native SQL joins should be used instead of PL/SQL constructs such as loops and cursors. Native SQL joins are more efficient and can improve the performance of the code. Additionally, using native SQL joins can help to make the code more readable and maintainable.

Maintainability Major NATURAL JOIN queries should not be used

The rule "NATURAL JOIN queries should not be used" states that when writing PL/SQL code, the use of NATURAL JOIN queries should be avoided. NATURAL JOIN queries are a type of SQL query that combines two or more tables by matching all columns with the same name. This type of query can lead to unexpected results and should be avoided in favor of explicit JOIN queries that specify the columns to be joined.

Maintainability Major Nested blocks should be labeled

The "Nested blocks should be labeled" rule states that when writing PL/SQL code, all nested blocks should be labeled with a unique identifier. This helps to make the code more readable and easier to debug. Labels should be descriptive and should include the type of block (e.g. IF, LOOP, etc.) as well as the purpose of the block. Labels should be placed at the beginning of the block and should be followed by a colon. This rule helps to ensure that the code is easier to understand and maintain.

Maintainability Major Nested loops should be labeled

The rule "Nested loops should be labeled" states that when writing PL/SQL code, each loop should be labeled with a unique identifier. This helps to easily identify and debug the loop when necessary. Labeling nested loops also helps to improve the readability of the code, making it easier to understand and maintain.

Maintainability Major Nested subqueries should be avoided

The rule "Nested subqueries should be avoided" states that when writing PL/SQL code, nested subqueries should be avoided whenever possible. Nested subqueries are subqueries that are nested within other subqueries, and can lead to complex and inefficient code. Instead, it is recommended to use joins or correlated subqueries to achieve the same result with simpler and more efficient code.

Maintainability Critical Newline and control characters should not be used in string literals

The rule "Newline and control characters should not be used in string literals" in PL/SQL code means that when writing a string literal, the programmer should avoid using any newline or control characters. This is because these characters can cause unexpected results when the code is executed. For example, if a newline character is used in a string literal, it could cause the string to be split into multiple lines when printed. Similarly, if a control character is used, it could cause unexpected behavior when the code is executed. Therefore, it is important to avoid using newline and control characters in string literals when writing PL/SQL code.

Maintainability Major NUMBER variables should be declared with precision

The rule "NUMBER variables should be declared with precision" states that when declaring a NUMBER variable in PL/SQL, the precision should be specified. This means that the total number of digits and the number of digits to the right of the decimal point should be specified. This helps to ensure that the variable can store the desired value without any loss of precision.

Maintainability Minor Object attributes should comply with a naming convention

The Pl_Sql code rule "Object attributes should comply with a naming convention" states that all object attributes must adhere to a consistent naming convention. This ensures that the code is easier to read and understand, and that any changes to the code can be quickly identified. The naming convention should be documented and followed by all developers, and should include rules for capitalization, abbreviations, and the use of underscores. This will help to ensure that the code is consistent and maintainable.

Maintainability Minor Objects should not be duplicated (same name and same type)

The Pl_Sql code rule "Objects should not be duplicated (same name and same type)" means that objects within a Pl_Sql program should not have the same name and same type. This is because having multiple objects with the same name and type can lead to confusion and errors in the program. It is important to ensure that each object has a unique name and type to avoid any potential issues.

Maintainability Minor Oracle's join operator (+) should not be used

Oracle's join operator (+) should not be used as it is an outdated syntax that can lead to unexpected results. It is recommended to use the ANSI-standard JOIN syntax instead, which is more explicit and easier to read. Additionally, the ANSI-standard JOIN syntax is more efficient and can lead to better query performance.

Maintainability Minor Package names should comply with a naming convention

The rule "Package names should comply with a naming convention" states that when creating a package in PL/SQL, the package name should adhere to a specific naming convention. This naming convention should be consistent and easy to understand, and should be used for all packages created in the database. The naming convention should also be documented and shared with all developers who will be using the package. This will ensure that all packages are easily identifiable and that their purpose is clear. Additionally, it will help to prevent confusion and reduce the risk of errors.

Maintainability Minor Parameter IN mode should be specified explicitly

The rule "Parameter IN mode should be specified explicitly" states that when writing PL/SQL code, all parameters passed to a procedure or function must be explicitly declared as either IN or OUT parameters. This ensures that the code is clear and easy to understand, and that any potential errors are avoided. By explicitly declaring the mode of the parameter, the code is more self-documenting and easier to debug.

Maintainability Minor PLS_INTEGER types should be used

The rule "PLS_INTEGER types should be used" states that the PLS_INTEGER data type should be used when declaring variables, constants, and parameters in a PL/SQL program. PLS_INTEGER is a data type that is specifically designed for use in PL/SQL programs. It is a 32-bit signed integer data type that can store values between -2,147,483,648 and 2,147,483,647. This data type is more efficient than other integer data types, such as NUMBER, and is more reliable when dealing with large numbers. Using PLS_INTEGER types can help to improve the performance of a PL/SQL program.

Maintainability Major Procedures and functions should be encapsulated in packages

Encapsulating procedures and functions in packages is a best practice in PL/SQL programming. By doing so, you can group related procedures and functions together, and make them easier to find and maintain. It also allows you to control access to the procedures and functions, and to control the order in which they are loaded into memory. Additionally, it allows you to create global variables that can be used across multiple procedures and functions. Packages also help to improve performance, since all the related code is loaded into memory at once, rather than having to be loaded each time it is used.

Maintainability Major Procedures should have parameters

The rule that "Procedures should have parameters" states that when creating a procedure in PL/SQL, it should include parameters. Parameters are variables that are passed to the procedure when it is called. They can be used to provide input to the procedure, and they can also be used to return values from the procedure. By using parameters, a procedure can be more flexible and reusable. It can be used in different contexts and can be called with different values. This makes it easier to maintain and debug, and it also makes it easier to use the procedure in different applications.

Maintainability Minor Procedures should not contain RETURN statements

The rule that "Procedures should not contain RETURN statements" is an important one for PL/SQL code. This rule ensures that the procedure will always execute completely, regardless of the number of times it is called. A RETURN statement will cause the procedure to exit immediately, which can lead to unexpected results. Additionally, a RETURN statement can make it difficult to debug the procedure, as the code will not be executed in its entirety. By avoiding the use of RETURN statements in procedures, developers can ensure that the code will always execute as expected.

Maintainability Major Queries should not SELECT too many columns

The Pl_Sql code rule "Queries should not SELECT too many columns" states that when writing SQL queries, it is best to only select the columns that are necessary for the query. Selecting too many columns can lead to performance issues, as the query will take longer to execute. Additionally, selecting too many columns can lead to confusion and make it difficult to interpret the results. It is best to only select the columns that are necessary for the query, and avoid selecting any unnecessary columns.

Maintainability Critical Quoted identifiers should not be used

The rule "Quoted identifiers should not be used" states that when writing PL/SQL code, it is best practice to avoid using quoted identifiers. Quoted identifiers are names of objects in the database that are surrounded by double quotes. These identifiers are case-sensitive and can cause confusion and errors. It is better to use unquoted identifiers, which are not case-sensitive and are easier to read and understand. Unquoted identifiers should be used whenever possible.

Maintainability Minor Record fields should comply with a naming convention

The Pl/SQL code rule "Record fields should comply with a naming convention" means that all record fields should be named in a consistent manner. This helps to ensure that the code is easier to read and understand. It also helps to prevent errors caused by typos or other mistakes. A naming convention could include using all lowercase letters, using underscores to separate words, and using prefixes or suffixes to indicate the data type of the field. Following a naming convention also helps to ensure that the code is consistent and organized.

Maintainability Major Redundant pairs of parentheses should be removed

This rule states that any redundant pairs of parentheses should be removed from PL/SQL code. This is to ensure that the code is written in a concise and clear manner, and to reduce the amount of unnecessary characters in the code. Redundant parentheses can be identified by looking for pairs of parentheses that are not necessary for the code to be syntactically correct. By removing these pairs of parentheses, the code will be easier to read and understand.

Maintainability Major RESULT_CACHE should not be used

The RESULT_CACHE rule states that the RESULT_CACHE hint should not be used in PL/SQL code. This is because the RESULT_CACHE hint can cause unexpected performance issues, and can lead to incorrect results. The RESULT_CACHE hint should only be used in very specific cases, and should be tested thoroughly before being used in production code.

Maintainability Minor Return of boolean expressions should not be wrapped into an if-then -else statement

The rule "Return of boolean expressions should not be wrapped into an if-then -else statement" in PL/SQL code means that boolean expressions should be returned directly without the need for an if-then-else statement. This is because boolean expressions already return either true or false, so there is no need to wrap them in an if-then-else statement. This makes the code more efficient and easier to read.

Maintainability Major ROWID and UROWID data types should not be used

The rule "ROWID and UROWID data types should not be used" states that the ROWID and UROWID data types should not be used in PL/SQL code. These data types are used to store the physical address of a row in a database table, and are not intended to be used in PL/SQL code. Using these data types can lead to unexpected results, and should be avoided.

Maintainability Minor Scripts must be commented

The rule "Scripts must be commented" states that all PL/SQL scripts must be accompanied by comments that explain the purpose of the code and any other relevant information. This helps to ensure that the code is understandable and maintainable, and can help to identify potential errors. Additionally, it allows for easier debugging and troubleshooting of the code. By commenting code, developers can ensure that their code is understood by other developers and can be easily modified or updated in the future.

Maintainability Minor Scripts must not exceed a certain size

The Pl_Sql code rule "Scripts must not exceed a certain size" states that all scripts written in Pl_Sql must not exceed a predetermined size limit. This rule is in place to ensure that scripts remain manageable and efficient, and that they do not become too large and unwieldy. This rule helps to ensure that scripts are written in a way that is easy to read, debug, and maintain. It also helps to prevent scripts from becoming too complex and difficult to understand.

Maintainability Critical SELECT statements used as argument of EXISTS statements should be selective

The SELECT statement used as argument of EXISTS statements should be selective, meaning that it should only return a few rows. This is important because the EXISTS statement only checks whether any rows are returned, not the actual number of rows. If the SELECT statement returns too many rows, the EXISTS statement may return a false positive, which can lead to unexpected results. Therefore, it is important to ensure that the SELECT statement is selective and only returns a few rows.

Maintainability Major SIMPLE_INTEGER should be used instead of PLS_INTEGER

The rule "SIMPLE_INTEGER should be used instead of PLS_INTEGER" states that the SIMPLE_INTEGER data type should be used instead of the PLS_INTEGER data type when declaring variables in PL/SQL code. SIMPLE_INTEGER is a 32-bit signed integer data type, while PLS_INTEGER is a 64-bit signed integer data type. Using SIMPLE_INTEGER instead of PLS_INTEGER will result in more efficient code, as SIMPLE_INTEGER is a smaller data type and requires less memory. Additionally, SIMPLE_INTEGER is more portable, as it is supported by all Oracle databases.

Maintainability Minor Single line comments should start with --

The rule "Single line comments should start with --" states that any single line comments in PL/SQL code should begin with two hyphens (--). This is used to differentiate comments from other code, and to ensure that the comments are properly identified and ignored by the PL/SQL interpreter.

Maintainability Major SQL EXISTS subqueries should not be used

The rule "SQL EXISTS subqueries should not be used" states that the SQL EXISTS subquery should not be used in a query. EXISTS subqueries are used to check if a certain condition is met in a table. They are usually used to check if a certain record exists in a table. However, using EXISTS subqueries can lead to performance issues and should be avoided. Instead, other methods such as joins should be used to check if a certain record exists in a table.

Maintainability Critical SQL JOIN conditions should involve all joined tables

The SQL JOIN condition rule states that when using JOINs in SQL, all tables involved in the JOIN must be specified in the JOIN condition. This ensures that the JOIN is performed correctly and that the results of the query are accurate. This rule also helps to prevent any unexpected results from occurring due to incorrect JOINs. By specifying all tables involved in the JOIN, the query will be more efficient and the results will be more accurate.

Maintainability Major SQL statements should not join too many tables

The rule "SQL statements should not join too many tables" states that SQL statements should be kept simple and should not join more than a few tables. This rule is important to follow because joining too many tables can lead to slower query performance, and can make the SQL statement more difficult to read and understand. Additionally, it can lead to data integrity issues if the tables are not properly joined. It is best to limit the number of tables joined in a single SQL statement to ensure that the query is efficient and the data is accurate.

Maintainability Minor SQL tables should be joined with the JOIN keyword

The rule "SQL tables should be joined with the JOIN keyword" states that when two or more tables are being combined in a SQL query, the JOIN keyword should be used to join the tables together. This ensures that the query is properly structured and that the data is properly retrieved from the database. The JOIN keyword allows for the use of various types of joins such as inner, left, right, and full outer joins. This allows the query to be more specific and to retrieve only the data that is needed. Additionally, the JOIN keyword allows for the use of various types of conditions such as equality, inequality, and range conditions. This allows for more flexibility when writing SQL queries.

Maintainability Major Statements should be on separate lines The Pl_Sql code rule "Statements should be on separate lines" states that each individual statement within a Pl_Sql code block should be on its own line. This helps to improve readability and makes it easier to debug any errors that may occur. It also helps to make the code more organized and easier to maintain.
Maintainability Minor String literals should not be duplicated

The rule "String literals should not be duplicated" states that when writing PL/SQL code, string literals should not be repeated unnecessarily. This means that when a string literal is used multiple times in a code block, it should be assigned to a variable and then the variable should be used instead of the literal. This helps to improve code readability and maintainability, as well as reducing the amount of code that needs to be written.

Maintainability Major Tables should be aliased

When writing PL/SQL code, it is good practice to alias tables in order to make the code more readable and easier to maintain. Aliasing a table is done by assigning a shorter name to a table, which is then used in the code instead of the full table name. This makes the code more concise and easier to read, as well as easier to maintain if the table name changes in the future. Aliasing tables is also useful when joining multiple tables, as it can help to avoid confusion when referencing columns from multiple tables.

Maintainability Minor The RELIES_ON clause should not be used

The RELIES_ON clause should not be used as it can lead to unexpected results and can cause the code to be difficult to maintain. This clause is used to indicate that the execution of a particular statement depends on the successful execution of a previous statement. This can lead to unpredictable results and can cause the code to become difficult to maintain. Additionally, it can also lead to performance issues as the code may not be optimized for the best performance. Therefore, it is best to avoid using the RELIES_ON clause in PL/SQL code.

Maintainability Major TO_DATE and TO_TIMESTAMP should be used with a datetime format model

The TO_DATE and TO_TIMESTAMP code rules state that when using these functions, a datetime format model should be used. This ensures that the data is stored in the correct format and that the correct information is retrieved from the database. The datetime format model provides a standard way of representing dates and times, which helps to ensure accuracy and consistency across the application. It also helps to prevent errors that can occur when data is stored in an incorrect format.

Maintainability Major TO_NUMBER should be used with a format model The TO_NUMBER function should be used with a format model when converting a character string to a number. The format model is a template that specifies how the character string should be parsed and converted into a number. It consists of one or more format elements, which are separated by commas. Each format element specifies how a portion of the character string should be converted into a number.
Maintainability Major Track breaches of an XPath rule The XPath rule is a set of rules that are used to define the structure and content of an XML document. The XPath rule is used to track any breaches of the rule, such as incorrect syntax, missing elements, or incorrect values. The PL/SQL code rule is used to detect any violations of the XPath rule and alert the user. This code rule can be used to ensure that the XML document is valid and conforms to the XPath rule. The PL/SQL code rule can also be used to validate the data in the XML document, ensuring that it is accurate and up-to-date. This code rule can be used to detect any errors or inconsistencies in the XML document and alert the user.
Maintainability Major Track comments matching a regular expression The Pl_Sql code rule "Track comments matching a regular expression" is used to identify and track comments in a program that match a given regular expression. This rule can be used to identify and track comments that contain specific keywords or phrases, or to identify and track comments that follow a specific pattern. This rule can be used to ensure that comments are consistent and adhere to a specific coding standard.
Maintainability Major Track uses of FIXME tags The PL/SQL code rule "Track uses of FIXME tags" is used to track the use of FIXME tags in PL/SQL code. FIXME tags are used to indicate areas of code that require attention or further investigation. This rule will help to identify any code that contains FIXME tags, so that they can be addressed quickly and efficiently. This rule will also help to ensure that any code that contains FIXME tags is properly documented and maintained.
Maintainability Major Track uses of NOSONAR comments The Pl_Sql code rule "Track uses of NOSONAR comments" is used to track the use of NOSONAR comments in a program. NOSONAR comments are used to indicate that a particular piece of code should not be analyzed by a static code analysis tool. This rule helps to ensure that code is properly analyzed and that any potential issues are identified.
Maintainability Information Track uses of TODO tags The Pl_Sql code rule "Track uses of TODO tags" is used to track the use of TODO tags in the code. This rule is used to identify any code that has been marked with a TODO tag, which is a comment that is used to indicate that a certain task needs to be completed. This rule helps to ensure that all tasks that have been marked with a TODO tag are completed in a timely manner. This rule also helps to identify any code that may have been forgotten or overlooked.
Maintainability Major Two branches in a conditional structure should not have exactly the same implementation

The PL/SQL code rule "Two branches in a conditional structure should not have exactly the same implementation" states that when using a conditional structure such as an IF/ELSE statement, the two branches should not contain the same code. This means that the code should differ in some way, either in the code itself or in the outcome. This rule helps ensure that the code is more robust and that any unexpected behavior can be easily identified and corrected.

Maintainability Minor Types should follow a naming convention

The rule "Types should follow a naming convention" states that all PL/SQL types should be named in a consistent and logical manner. This helps to ensure that the code is easier to read and understand. Naming conventions should include prefixes, suffixes, and capitalization to distinguish between different types. For example, a type that stores a customer's name could be named "CUST_NAME_TYPE". This helps to make the code more readable and easier to maintain. Additionally, it can help to prevent naming conflicts between different types.

Maintainability Major UNION should be used with caution

The rule "UNION should be used with caution" in PL/SQL code means that when using the UNION operator, developers should be aware of the potential side effects. This is because UNION combines the results of two or more SELECT statements into a single result set, and can cause unexpected results if not used correctly. Developers should ensure that the columns being combined are compatible, and that the data types of the columns being combined are the same. Additionally, developers should be aware of the potential for duplicate records when using UNION, and should use the UNION ALL operator to prevent this from happening.

Maintainability Major Unused labels should be removed

The rule of "Unused Labels should be removed" in PL/SQL code states that any labels that are not used in the code should be removed. This is important because unused labels can lead to confusion and can make the code difficult to read and understand. Additionally, having too many labels can slow down the performance of the code. Therefore, it is important to ensure that all unused labels are removed from the code to improve readability and performance.

Maintainability Minor Unused local variables should be removed

The rule "Unused local variables should be removed" states that any local variables declared in a PL/SQL code block that are not used should be removed. This is to ensure that the code is as efficient as possible, and that any unnecessary code is not taking up space. Unused variables can also lead to confusion and errors, so it is important to remove them in order to keep the code clean and organized.

Maintainability Major Unused Procedure and Function Parameters

The Unused Procedure and Function Parameters rule checks for unused parameters in stored procedures and functions. This rule helps to identify and eliminate unnecessary parameters that can lead to code bloat and confusion. Unused parameters can also lead to potential security vulnerabilities if they are not properly handled. The rule checks for parameters that are declared but not used in the body of the procedure or function. If any unused parameters are found, the rule will generate a warning.

Maintainability Major VARCHAR2 should be used

The rule "VARCHAR2 should be used" states that the VARCHAR2 data type should be used when creating variables, columns, and parameters in PL/SQL code. VARCHAR2 is a data type that stores variable-length character strings up to 4000 characters in length. It is the preferred data type for storing character strings in PL/SQL code, as it is more efficient than the CHAR data type and can be used to store strings of varying lengths. Using VARCHAR2 instead of CHAR can help reduce the amount of memory used and improve the performance of the code.

Maintainability Minor Variables Naming Convention

The Pl/SQL Variables Naming Convention is a set of rules for naming variables in the Pl/SQL programming language. This convention helps to ensure that variables are named in a consistent and logical manner, making code easier to read and understand. The convention states that all variables should be named using only alphanumeric characters, and should begin with a letter. Variables should also be named in a descriptive manner, using words that accurately describe the purpose of the variable. Additionally, variables should be named using a combination of lowercase and uppercase letters, with the first letter of each word in the variable name being uppercase. This helps to make the variable name more readable and easier to understand.

Maintainability Major Variables should be nullable

The Pl_Sql code rule "Variables should be nullable" states that variables should be declared with the NULL keyword, allowing them to accept a NULL value. This is important because it allows the variable to accept a NULL value without generating an error. This is especially useful when dealing with database operations, as it allows for the possibility of missing or unknown values. This rule also helps to ensure that the code is more robust and can handle unexpected data.

Maintainability Minor Variables should not be initialized with NULL

The Pl_Sql code rule "Variables should not be initialized with NULL" states that variables should not be assigned the value NULL when they are declared. This is because NULL is a special value that indicates that the variable has no value assigned to it. Instead, variables should be assigned an appropriate value that reflects the data type of the variable. This will ensure that the variable is properly initialized and can be used in the code.

Maintainability Critical Weak REF CURSOR types should not be used

The rule "Weak REF CURSOR types should not be used" states that weak REF CURSOR types should not be used in PL/SQL code. A weak REF CURSOR type is a type of cursor that is not strongly typed, meaning that it can return any type of data. This can lead to unexpected results and can make code more difficult to debug. It is therefore recommended to use strongly typed REF CURSOR types instead, which are more reliable and easier to debug.

Maintainability Major WHEN clauses should not have too many lines

The rule "WHEN clauses should not have too many lines" states that when writing PL/SQL code, the WHEN clauses should be kept as concise as possible. This means that the code should be written in such a way that the WHEN clauses are not too long or complex, as this can make the code difficult to read and understand. It is recommended that the WHEN clauses should be kept to a maximum of three lines, and that any complex logic should be broken up into smaller, more manageable chunks. This will help to ensure that the code is easier to read and understand, and that any potential errors can be quickly identified and resolved.

Maintainability Critical WHEN OTHERS clauses should be used for exception handling

The WHEN OTHERS clauses should be used for exception handling in PL/SQL code. This clause is used to catch any exceptions that are not explicitly handled by the code. It is important to use this clause as it allows the code to handle unexpected errors and prevents the code from crashing. This clause should be used in conjunction with other exception handling techniques such as using the RAISE statement and using the EXCEPTION_INIT pragma. This clause should also be used to log any errors that occur during execution of the code.

Maintainability Critical WHEN OTHERS should not be the only exception handler

The rule "WHEN OTHERS should not be the only exception handler" states that when writing PL/SQL code, you should not rely solely on the WHEN OTHERS exception handler. Instead, you should create specific exception handlers for each exception that you anticipate. This will allow you to handle each exception in a specific way, rather than relying on a generic exception handler. This will also make your code more efficient, as it will not have to process each exception in the same way. By creating specific exception handlers, you can also provide more meaningful error messages to the user, which will help them to understand and fix the issue more quickly.