Home

Code Rules

Display all the rules belongs to Power Builder language.

Category Severity Name Description
Bug Major All branches in a conditional structure should not have exactly the same implementation

The "All branches in a conditional structure should not have exactly the same implementation" PowerBuilder code rule states that all branches in a conditional structure should have distinct implementations. This means that each branch should have its own distinct logic and code, rather than having the same code repeated across multiple branches. This helps to ensure that the code is clear and easy to read, and that the logic of the code is sound and consistent. Additionally, it helps to avoid potential errors that could arise from having multiple branches with the same implementation.

Vulnerability Critical Always use AES encryption algorithm in a secure mode

The PowerBuilder code rule "Always use AES encryption algorithm in a secure mode" requires that developers use the Advanced Encryption Standard (AES) algorithm for all encryption operations. AES is a symmetric encryption algorithm that is considered to be one of the strongest and most reliable encryption algorithms available. When using AES encryption, it is important to always use a secure mode, such as Cipher Block Chaining (CBC) or Galois/Counter Mode (GCM). This ensures that the encrypted data is secure and not susceptible to attacks.

Maintainability Minor Boolean checks should not be inverted

The PowerBuilder code rule "Boolean checks should not be inverted" states that a Boolean check should not be written in a way that would cause it to evaluate to the opposite of what is intended. This means that when writing code, it is important to be aware of the logical structure of the code and ensure that any Boolean checks are written in the correct order. This will ensure that the code behaves as expected and does not produce unexpected results.

Maintainability Minor Boolean literals should not be redundant

The "Boolean literals should not be redundant" rule states that when writing PowerBuilder code, Boolean literals (true/false) should not be used redundantly. This means that if a Boolean value is already established, it should not be repeated unnecessarily. For example, if a Boolean value has already been set to "true," it should not be written again as "true" in the same code.

Maintainability Critical Calling the Java class in PowerBuilder is no longer supported

The rule states that "Calling the Java class in PowerBuilder is no longer supported in PowerBuilder 2022", this means that developers can no longer use these objects in their PowerBuilder 2022 applications, and any existing applications that were built with these objects will need to be updated to use other methods. o The EJBConnection, EJBTransaction, and JavaVM objects are no longer supported. Also The CreateJavaVM function is no longer supported. This change reflects the changing landscape of application development and the need for developers to use more modern methods and technologies.

Maintainability Major CASE clauses should not have too many lines

The "CASE clauses should not have too many lines" PowerBuilder code rule states that when writing code using the CASE statement, the number of lines within each clause should be kept to a minimum. This helps to improve the readability of the code, makes it easier to debug, and reduces the chances of introducing errors. Additionally, it is recommended that the CASE statement be used only when absolutely necessary, and that alternative approaches such as IF/ELSE statements be used instead when possible. This helps to keep the code concise and easier to maintain.

Maintainability Critical CASE expressions should end with ELSE clauses

The "CASE expressions should end with ELSE clauses" rule states that all CASE expressions used in PowerBuilder code should be concluded with an ELSE clause, regardless of whether the ELSE clause contains any code or not. This is done to ensure that all possible cases are accounted for in the CASE expression, and that the code is robust and reliable. Without an ELSE clause, a CASE expression may not be able to handle unexpected inputs or values, which can cause the code to fail or produce unexpected results.

Maintainability Minor CASE should be used for sequences of simple tests

The "CASE should be used for sequences of simple tests" PowerBuilder code rule states that the CASE statement should be used when there are multiple, simple tests that need to be performed, instead of using a series of IF statements. The CASE statement is more efficient and easier to read than multiple IF statements, as it allows for a single expression to be evaluated and compared against multiple values, with each value having its own corresponding action. It also allows for a default action to be taken if none of the values match the expression.

Maintainability Major CASE structures should not have too many CASE clauses

The "CASE structures should not have too many CASE clauses" rule states that when using CASE structures in PowerBuilder code, the number of CASE clauses should be kept to a manageable amount. This is because too many CASE clauses can make the code difficult to read and understand, and can also lead to performance issues. It's best to use other methods to structure the code if possible, such as using IF/ELSE statements. If CASE structures must be used, it's important to keep the number of clauses to a minimum.

Maintainability Minor Code elements must not be unused

This PowerBuilder code rule states that all code elements must not be unused. This means that all elements of the code, such as variables, functions, classes, and other code elements, must be used in the code in order to be considered valid. If a code element is unused, it should be removed from the code in order to make the code more efficient and reduce the risk of errors. Unused code elements can also create confusion for other developers, as they may not understand why the code element is there if it is not being used. It is important to ensure that all code elements are used appropriately in order to create clean, efficient code.

Maintainability Major Collapsible if statements should be merged

The "Collapsible if statements should be merged" rule states that when multiple if statements can be combined into a single if statement, they should be merged. This helps to make code more concise and easier to read, as well as reducing the overall complexity of the code. It also helps to avoid potential errors that can occur when multiple if statements are used. For example, if two if statements are used to check for a condition, but the first statement fails, the second statement will still be executed, even though the condition was already checked. By merging the two statements into one, this potential error can be avoided.

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

This rule states that comments should not be placed at the end of lines of code in PowerBuilder. This is because comments at the end of lines can be misinterpreted as part of the code, leading to potential errors. It is best to place comments on their own line, or at the beginning of the line of code, so that they are clearly separated from the code.

Vulnerability Critical Cryptographic Hash Functions should not use SHA-1 or Message-Digest Algorithms

This rule states that when using cryptographic hash functions, SHA-1 or Message-Digest Algorithms should not be used. Cryptographic hash functions are used to provide a secure way of verifying the integrity of data. SHA-1 and Message-Digest Algorithms are known to be vulnerable to attack, so it is important to use stronger algorithms to ensure the data is secure.

Vulnerability Critical Database queries should not be vulnerable to injection attacks

This PowerBuilder code rule states that database queries should be constructed in such a way that they are not vulnerable to injection attacks. An injection attack is a type of malicious attack in which malicious code is inserted into a query in order to gain access to or manipulate data. To prevent such attacks, code should be written to ensure that user input is sanitized and that queries are constructed properly so that malicious code is not able to be injected into them.

Maintainability Critical DDE functions and events are Obsoleted

The PowerBuilder code rule "DDE functions and events are Obsoleted" states that the use of Dynamic Data Exchange (DDE) functions and events should be avoided as they are no longer supported in new versions of PowerBuilder. Developers should use alternative methods for data exchange, such as OLE Automation or web services.

Vulnerability Critical DES (Data Encryption Standard) or 3DES should not be used

This rule states that the Data Encryption Standard (DES) or Triple DES (3DES) should not be used in PowerBuilder code. DES and 3DES are outdated encryption algorithms, and are considered to be weak and insecure. It is recommended to use more modern and secure algorithms such as AES or RSA for encryption.

Vulnerability Critical Encryption algorithms must be used with the appropriate secure mode and padding scheme.

This rule states that when using encryption algorithms, they must be used in conjunction with the appropriate secure mode and padding scheme in order to ensure the security of the data being encrypted.

Vulnerability Critical Encryption keys should be long enough

The rule "Encryption keys should be long enough" states that encryption keys used to protect sensitive data should be of a sufficient length to provide an adequate level of security. The longer the key, the more secure the data will be. Generally, the longer the key, the more difficult it is for an attacker to guess or crack the key. It is important to use strong encryption keys that are at least 128 bits long to ensure that the data is sufficiently protected.

Vulnerability Critical Encryption keys should not be hardcoded

The PowerBuilder code rule "Encryption keys should not be hardcoded" states that any encryption keys used in PowerBuilder code should not be stored as plain text in the code. Instead, the encryption keys should be stored in a secure location outside of the code and referenced from there. This ensures that the encryption keys are kept secure and not exposed to potential attackers who may be able to access the code. It also makes it easier to manage the keys in the event that they need to be changed or updated.

Maintainability Minor EXIT should not be used in loops

The EXIT should not be used in loops rule states that the EXIT statement should not be used to exit from a loop. Instead, the loop should be exited by using the appropriate looping construct, such as the EXIT WHEN or EXIT FOR statements. This rule ensures that code is properly structured and that loops are exited in a predictable and consistent manner.

Maintainability Minor Fields should not have public accessibility

This rule states that fields in PowerBuilder code should not be made publicly accessible. This means that they should not be declared as public variables, and should instead be declared as private or protected variables. This is important because making fields publicly accessible could open up the code to potential security risks, as it would allow external code to access and modify the fields without any restrictions. It is also important to ensure that fields are only accessible by code that is within the same class, as this will help to ensure that the code is secure and that it is only modified in the intended way.

Maintainability Major Files should not have too many lines of code

This rule states that files should not contain too many lines of code. This is to ensure that the code is well-structured, easy to read and maintain, and that the code is logically organized. It is also important to ensure that the code is not overly complicated or difficult to understand. This rule is especially important for larger projects, where the code can become difficult to manage if it is too long or convoluted. It is also important to keep the code organized in a way that is easy to understand and navigate. By limiting the length of each file, developers can ensure that their code is well-structured and easy to maintain.

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

This rule states that the end conditions of a FOR loop should not be hard-coded. This means that the end conditions should be determined dynamically based on the data being processed by the loop. Hard-coding end conditions can lead to errors and inefficiencies in the code. It is better to use variables or other expressions to set the end conditions so that the loop can be more flexible and adaptable to different data sets.

Maintainability Critical Forward prototype should not contains duplicate function declarations

The "Forward Prototype Should Not Contain Duplicate Function Declarations" rule states that PowerBuilder code should not contain multiple declarations of the same function within a single forward prototype. This rule is intended to ensure that the code is organized and readable, and that the same function is not declared multiple times in the same forward prototype. If the same function is declared multiple times in the same forward prototype, it can lead to confusion and errors in the code. This rule also helps to ensure that the code is easy to maintain and debug.

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

This PowerBuilder code rule states that function and event parameters must follow a specific naming convention. This convention helps to ensure that the code is consistent and easier to read. The naming convention should include a prefix for each type of parameter, such as “in_” for input parameters, “out_” for output parameters, and “inout_” for parameters that are both input and output. This makes it easier to identify the purpose of each parameter when reading the code.

Maintainability Major Function OR Event name should comply with a naming convention

This rule states that all functions and events in PowerBuilder code should follow a specific naming convention. This naming convention should be consistent throughout the code and should be easy to understand. The naming convention should also make it easy to distinguish between functions and events, as well as other types of code elements. This will help to make the code more organized and easier to read and maintain.

Bug Major Function return type does not match with the actual variable returned

This rule states that a function's return type must match the type of the variable that is actually returned. For example, if a function is declared as returning an integer, then the function must return an integer value. If a function is declared as returning a string, then the function must return a string value. If the actual return value does not match the declared return type, then the code will not compile.

Maintainability Major Functions Or Events should not have too many parameters

This rule states that functions or events should not have too many parameters. Having too many parameters can make the code difficult to read and understand, and can lead to errors. It is best practice to limit the number of parameters to a manageable number, usually no more than 5-10. Any more than that should be split into multiple functions or events. This will help make the code more readable and easier to maintain.

Bug Critical Functions should end with RETURN statements

The PowerBuilder code rule that states "Functions should end with RETURN statements" means that all functions should include a RETURN statement as the last line of code. This statement is used to indicate the end of the function and to return a value to the calling program. By using RETURN statements, code can be written in a more organized and efficient manner, as well as making it easier for other developers to understand and debug the code.

Maintainability Minor Generic exceptions should not be ignored

The "Generic exceptions should not be ignored" rule for PowerBuilder code states that all exceptions should be handled appropriately, and not just ignored. This means that a developer should not simply ignore an exception that occurs in the code, but instead should take the time to investigate the cause of the exception and handle it in the appropriate manner. This could include using a try-catch block, logging the exception, or simply displaying an error message to the user. Ignoring an exception can lead to errors or unexpected results in the application, so it is important to always handle exceptions appropriately.

Maintainability Critical GOTO should not be used to jump backwards

The "GOTO should not be used to jump backwards" PowerBuilder code rule states that the GOTO statement should not be used to jump backwards to a previous line of code. This is because it can create confusion and make debugging difficult. Instead, the code should be restructured to use loops, functions, and other control statements to make the code easier to read and understand.

Maintainability Major GOTO should not be used within loops

The PowerBuilder code rule stating that "GOTO should not be used within loops" is an important guideline for developers to adhere to when writing code. This rule is designed to prevent unexpected behavior and to make the code easier to read and maintain. By avoiding the use of GOTO statements within loops, developers can ensure that their code is more organized, less prone to errors, and easier to debug. Additionally, using GOTO statements within loops can lead to unexpected behavior, which can be difficult to diagnose and fix. Therefore, it is important to avoid the use of GOTO statements within loops in order to ensure code maintainability and reliability.

Maintainability Major GOTO statements should not be used

The "GOTO statements should not be used" PowerBuilder code rule states that GOTO statements should not be used in PowerBuilder code, as they can lead to code that is difficult to read and maintain. GOTO statements cause code to become "spaghetti code" - code that is difficult to follow and understand. Instead of using GOTO statements, it is better to use structured programming techniques such as looping and branching. These techniques make code easier to read and maintain, and can help to reduce errors in the code.

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

This rule states that IF...ELSEIF constructs should always end with an ELSE clause. This means that any IF...ELSEIF construct should have an ELSE clause at the end, which will be executed if none of the other conditions in the IF...ELSEIF construct are met. This ensures that all possible conditions are accounted for and that no unintended behavior occurs.

Bug Major IF statement conditions should not evaluate unconditionally to TRUE or to FALSE

The IF statement conditions should not evaluate unconditionally to TRUE or to FALSE rule is a guideline for PowerBuilder developers to ensure that their code is properly structured and functioning correctly. This rule states that IF statements should not contain conditions that will always evaluate to either TRUE or FALSE. Instead, the conditions should be dynamic and based on the values of variables or other conditions. This ensures that the IF statement will be executed correctly and that the desired results will be achieved. By following this rule, developers can avoid potential errors and maintain the integrity of their code.

Maintainability Major IF statements should not be nested too deeply

This rule states that IF statements should not be nested too deeply. This means that when writing code, the programmer should avoid writing nested IF statements that are too complex and difficult to read. Nested IF statements are when one IF statement is placed inside another IF statement. Too much nesting can make code hard to read and difficult to debug. To avoid this, the programmer should try to limit the amount of nesting and use other programming techniques to keep the code clear and readable.

Vulnerability Critical IP addresses should not be Hardcoded

The PowerBuilder code rule "IP addresses should not be Hardcoded" states that IP addresses should not be stored directly in the code, but should instead be stored in a configuration file. This allows the IP address to be changed without having to modify the code. This helps to ensure that the code is easier to maintain and allows for easier updates in the future.

Bug Major Jump statements should not be followed by dead code

The "Jump statements should not be followed by dead code" PowerBuilder code rule states that any jump statement (such as a "goto," "return," "exit," or "exit loop") should not be followed by code that will never be executed. This is considered bad programming practice, as it can lead to confusion and errors. It is best practice to ensure that any code following a jump statement is necessary and will be executed.

Maintainability Minor Jump statements should not be redundant

The "Jump statements should not be redundant" rule in PowerBuilder code states that jump statements, such as GOTO, EXIT, BREAK, and CONTINUE, should not be used unnecessarily. Unnecessary jump statements can make code harder to read and debug, as well as leading to unexpected behavior. When writing code, it is best to avoid redundant jump statements and use alternative control flow structures, such as loops and conditional statements, whenever possible.

Maintainability Minor Lines should not be too long

The rule "Lines should not be too long" states that PowerBuilder code should be written in a way that limits each line to a certain number of characters. This is to help improve readability of the code, as long lines can be difficult to read and understand. It also helps to keep the code organized and structured, as it can be easier to find errors or make changes when the code is written in a consistent manner. Additionally, long lines can cause performance issues, as the code may have to be parsed multiple times in order to be executed.

Maintainability Minor Lines should not end with trailing whitespaces

The PowerBuilder code rule "Lines should not end with trailing whitespaces" ensures that all lines of code in a program do not contain any unnecessary whitespace characters at the end of the line. This is important to maintain the readability and consistency of the code, as well as to prevent any potential errors that could be caused by the presence of these extra characters.

Bug Major Loops with at most one iteration should be refactored

The "Loops with at most one iteration should be refactored" rule in PowerBuilder code states that any loops which contain only one iteration of code should be refactored in order to make the code more efficient and easier to read. This means that instead of having a loop with just one iteration, the code should be rewritten to simply execute the code block without the loop. This can help to reduce the amount of code and make the code more understandable.

Maintainability Minor Methods must not be empty

This rule states that any methods created in PowerBuilder should not be empty. This means that each method should have some code within it that performs a specific task. This ensures that the code is well-structured, easy to read, and maintainable. Additionally, it prevents the code from becoming cluttered and difficult to debug.

Maintainability Minor Missing destructor

The Missing Destructor rule checks for PowerBuilder objects that are missing a destructor. A destructor is a method that is automatically called when an object is destroyed. It is used to free up any resources that the object has allocated, such as memory or file handles. If an object is missing a destructor, it can lead to memory leaks and other problems. This rule will generate a warning if an object is missing a destructor.

Maintainability Minor Naming conventions must be applied

The PowerBuilder code rule "Naming conventions must be applied" states that all objects, variables, and other elements of the code must be named according to the established naming conventions. This ensures that the code is consistent and easy to read, making it easier to understand and debug. It also helps to avoid confusion between different elements of the code. The naming conventions must be clearly defined and documented, and all developers must adhere to them.

Vulnerability Minor Never use Console logging in production

The rule "Never use Console logging in production" states that developers should never use Console logging when deploying their code to a production environment. Console logging is a debugging technique that allows developers to output information to the console window during code execution. While this can be useful for debugging purposes, it should not be used when the code is running in a production environment. This is because the information outputted to the console can be visible to users, which can lead to security and privacy issues. Additionally, the output from the console can also slow down the performance of the application, which can lead to an overall decrease in user experience. Therefore, it is best to avoid using Console logging in production environments.

Vulnerability Critical Never use CoSetProxyBlanket or CoInitializeSecurity

This rule states that developers should never use the CoSetProxyBlanket or CoInitializeSecurity APIs in PowerBuilder code. These APIs are used to set the authentication level for a COM object, which can be a security risk when used incorrectly. As such, they should be avoided when writing PowerBuilder code.

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

This rule states that when writing string literals in PowerBuilder code, newline and control characters should not be used. This is because these characters can cause unexpected behavior in the program, and can also be difficult to debug. It is best to stick to standard characters such as letters, numbers, and punctuation when writing string literals.

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

This rule states that objects should not be duplicated within the PowerBuilder code. This means that objects should not have the same name and type within the code. Duplicating objects can lead to confusion and errors, as the code may not be able to distinguish between the two objects. To avoid this, objects should be given unique names and types to ensure that the code runs correctly and that the objects are distinguishable from one another.

Vulnerability Critical OS commands should not allow injection attacks

The "OS commands should not allow injection attacks" rule states that when executing OS commands from PowerBuilder code, the commands should be validated to ensure that they cannot be used to inject malicious code into the system. This can be done by using parameterized queries, whitelisting accepted commands, or other methods of input validation. Additionally, the code should be written to ensure that any user-supplied data is properly escaped and sanitized to prevent malicious code from being injected into the system.

Maintainability Minor PBLs should not exceed a certain size

The rule "PBLs should not exceed a certain size" states that PowerBuilder Library (PBL) files should not be too large. This is important to ensure that the application runs efficiently and that it is not too difficult for developers to maintain. To ensure this, developers should limit the size of PBLs to a certain size, such as 2MB or 5MB, depending on the complexity of the application. This can be done by limiting the number of objects in the PBL, such as windows, user objects, and menus, and by ensuring that the code within each object is as efficient as possible. Additionally, developers should also periodically review the size of the PBLs and remove any unused objects or code.

Maintainability Major Redundant pairs of parentheses should be removed

The PowerBuilder code rule "Redundant pairs of parentheses should be removed" means that when writing PowerBuilder code, any redundant pairs of parentheses should be removed as they are not necessary and can make the code difficult to read and understand. Redundant parentheses can be removed by replacing them with a single set of parentheses or by simply removing them altogether. This rule helps to ensure that the code is well-structured and easier to read.

Vulnerability Critical Regular expressions should not allow Denial of Service attacks

This PowerBuilder code rule states that regular expressions should not be used in a way that could result in a Denial of Service (DoS) attack. A DoS attack is an attack that attempts to make a system or network resource unavailable to its intended users. Regular expressions can be used to match patterns in strings, but they can also be used to create malicious input that can overwhelm a system with requests. To prevent DoS attacks, regular expressions should be used with caution and be thoroughly tested before being deployed in a production environment.

Bug Major Related IF/ELSIF statements and WHEN clauses in a CASE should not have the same condition

This rule states that when using IF/ELSIF statements and WHEN clauses in a CASE statement, they should not have the same condition. This is because the conditions should be unique to each statement or clause, as having the same condition could result in an infinite loop or other unintended behavior. This rule helps ensure that the code is structured properly and that it runs as expected.

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

This PowerBuilder code rule states that boolean expressions should not be wrapped in an if-then-else statement. This means that when a boolean expression is used, the code should not be written in a way that requires an if-then-else statement to be used. The code should instead be written in a way that the boolean expression can be evaluated directly without the need for an if-then-else statement.

Maintainability Minor Scripts must be commented

This rule states that all scripts written in PowerBuilder must be commented. This means that any code written in a script must include comments that explain the purpose of the code and how it works. This will help other developers understand the code and make it easier to maintain. Additionally, comments can be used to document changes made to the code and to alert other developers of potential issues. Having well-commented code can also help with debugging and troubleshooting. Following this rule will help ensure that PowerBuilder code is well organized, easily maintained, and up to date.

Maintainability Minor Scripts must not exceed a certain size

This PowerBuilder code rule states that any scripts written must not exceed a certain size. This size is determined by the developer and can be set to whatever size is considered appropriate for the application. This rule helps ensure that scripts are organized and efficient, and that they do not become too large and difficult to maintain. This rule also encourages developers to break down large scripts into smaller, more manageable pieces. This helps to ensure that scripts are easier to read and maintain, and that they are more efficient and less prone to errors.

Vulnerability Critical SOAP and INET objects should not be used

This rule states that the SOAP and INET objects should not be used when writing PowerBuilder code. These objects are not supported by PowerBuilder and can cause instability and unexpected behavior. Instead, developers should use other supported objects such as the Web Service Proxy or the HTTP Client object. Using these objects will ensure that the code is stable and reliable.

Maintainability Major Statements should be on separate lines The PowerBuilder code rule "Statements should be on separate lines" states that each statement in a PowerBuilder program should be placed on a separate line. This helps to make the code more readable and easier to debug, as it is easier to identify individual statements when they are on separate lines. Additionally, this rule helps to ensure that any changes made to a particular statement are easily identifiable, as they will be on their own line.
Maintainability Minor String literals should not be duplicated

The "String literals should not be duplicated" PowerBuilder code rule states that when writing code, any string literals should be written only once. This means that when writing code, any strings that are used multiple times should be stored in a variable and the variable should be used instead of the literal string. This helps to make the code more efficient and maintainable, as any changes to the string can be done in one place instead of multiple places.

Bug Critical Syntax Errors

The PowerBuilder code rule "Syntax Errors" checks the syntax of PowerBuilder code for errors. This includes checking for missing semicolons, invalid keywords, and other syntax-related problems. The rule will report any syntax errors it finds, along with a description of the error and its location in the code. This helps developers quickly identify and fix any syntax-related issues in their PowerBuilder code.

Maintainability Critical The JDBC database interface is removed from the Database painter

The PowerBuilder code rule "The JDBC database interface is removed from the Database painter" means that the JDBC database interface is no longer available in the Database painter. This means that the Database painter will no longer be able to connect to databases using the JDBC interface. Instead, users will need to use other database interfaces to connect to databases.

Maintainability Critical The OData database interface is removed from the Database painter

The OData database interface has been removed from the Database painter in PowerBuilder code. This means that developers will no longer be able to access this interface from the Database painter, and instead must use other methods to access OData databases. This removal is likely intended to encourage developers to use more modern methods of accessing databases, such as through web services or through other more modern interfaces.

Vulnerability Critical The OLE web browser should not be used anymore (not secure)

The PowerBuilder code rule states that the OLE web browser should no longer be used, as it is not secure. This is because the OLE web browser is an outdated technology that is no longer supported or updated, and thus is vulnerable to security breaches. It is recommended that developers use more secure alternatives such as HTML or JavaScript.

Maintainability Critical The XSLFOP! PDF method is removed from PowerScript

The XSLFOP! PDF method has been removed from PowerScript in order to improve performance and reduce the complexity of the code. This method was used to generate PDF documents from PowerScript, but it was found to be inefficient and difficult to maintain. By removing this method, code will be simpler and more efficient, making it easier to maintain and debug. Additionally, the removal of this method will also improve the overall performance of PowerScript, as it will no longer need to process the unnecessary code.

Maintainability Major Track uses of FIXME tags

The PowerBuilder code rule "Track uses of FIXME tags" helps to keep track of any code that requires further attention or debugging. This rule will search through the code for any comments containing FIXME tags, and then log any instances of these tags in a log file. This log can then be used to quickly identify areas of the code that may need further attention or debugging. In addition, this rule can help developers to keep track of any tasks they need to complete, as well as any areas that may need to be refactored or improved.

Maintainability Information Track uses of TODO tags

The PowerBuilder code rule "Track uses of TODO tags" is used to track the use of TODO tags within code. TODO tags are used to denote items that need to be addressed in the future, such as bugs, features, or refactoring. This rule helps developers to keep track of these items and ensure that they are addressed in a timely manner.

The rule works by scanning the code for any TODO tags and then records the location of the tags in a log. This log can then be used to review the progress of the TODO items and ensure that they are addressed in a timely manner.

This rule can help to improve the quality of the code and ensure that any issues are addressed quickly and efficiently. It can also help to increase the visibility of any TODO items and ensure that they are addressed in a timely manner.

Maintainability Major Two branches in a conditional structure should not have exactly the same implementation

This rule states that when a conditional structure is used, the two branches should not have the same implementation. This means that the code executed in each branch should be different. This helps to ensure that the code is more organized and readable, and that the code runs as expected.

Maintainability Major Unused event parameters should be removed

This rule states that any event parameters that are not used in the PowerBuilder code should be removed. This is important because leaving unused event parameters can lead to unexpected behavior in the code, and can also lead to increased memory usage. Unused event parameters should be identified and removed to ensure the code is running optimally.

Maintainability Major Unused function parameters should be removed

The "Unused Function Parameters Should Be Removed" PowerBuilder code rule states that any function parameters that are not used within the body of the function should be removed. This helps to reduce the amount of code that needs to be maintained and ensures that unnecessary code is not included in the program. Additionally, it helps to improve readability by making the code easier to understand, and it can also improve performance by reducing the amount of code that needs to be processed.

Maintainability Minor Unused global variables/constants should be removed

This rule states that any global variables or constants that are not being used in the PowerBuilder code should be removed. This is important to keep the code clean and organized, and to avoid any unnecessary clutter. Unused variables and constants can also lead to potential errors or bugs in the code, so it is important to ensure that all global variables and constants are being used.

Maintainability Major Unused labels should be removed

This PowerBuilder code rule states that any labels which are no longer used in the code should be removed. This helps to ensure that the code is organized and easy to read, and that any unnecessary code is removed. Unused labels can be identified by searching the code for any labels which are not referenced anywhere else in the code. Once identified, these labels can be removed to help keep the code clean and organized.

Maintainability Minor Unused local variables should be removed

This rule states that all local variables that are declared but not used within a PowerBuilder code should be removed. This is to ensure that the code is as clean and efficient as possible, and that unnecessary variables are not taking up memory space. Additionally, this rule helps to identify any potential errors or typos that may have been made when declaring variables. By removing unused local variables, the code is easier to read, understand, and debug.

Maintainability Critical Use the LoadWithDotNet function instead of LoadWithDotNetFramework and LoadWithDotNetCore functions

Upgrade your .NET assembly to .NET 6.0 assembly and use the LoadWithDotNet function instead of LoadWithDotNetFramework and LoadWithDotNetCore functions, you must first ensure that your assembly is compatible with .NET 6.0. Once you have verified compatibility, you can use the LoadWithDotNet function to load the assembly into the PowerBuilder application. The LoadWithDotNet function is designed to work with .NET 6.0 assemblies, and it is a more efficient and reliable way to load assemblies compared to the LoadWithDotNetFramework and LoadWithDotNetCore functions.

Vulnerability Critical User IDs and Passwords should not be Hardcoded

This rule states that user IDs and passwords should not be hardcoded into any PowerBuilder code. This means that any references to user IDs and passwords should not be included in the code itself, but instead should be stored in a separate, secure location. This ensures that user credentials are kept confidential and secure, and that they can be easily updated when necessary.

Vulnerability Critical User input should not allow path injection or path transversal attacks

This PowerBuilder code rule states that user input should not be allowed to inject or traverse paths, as this could allow attackers to gain access to unauthorized areas of the system. Path injection and path transversal attacks involve maliciously manipulating the system's file paths to gain access to areas of the system that the user is not authorized to access. To prevent this, user input should be validated and filtered to ensure that only legitimate paths are allowed. Additionally, it is important to ensure that the system is configured to prevent users from accessing areas of the system that they do not have permission to access.

Maintainability Minor Variables should comply with a naming convention

The PowerBuilder code rule "Variables should comply with a naming convention" states that all variables used in a PowerBuilder application should be named according to a specific set of guidelines. This helps to ensure that all variables are easily identifiable and that they are used consistently throughout the code. The naming convention should specify the type of variable (e.g. integer, string, etc.), the length of the variable (if applicable), and any other specific requirements that may be applicable to the variable. By following a consistent naming convention, developers can ensure that their code is more organized, readable, and maintainable.

Bug Major Variables should not be self-assigned

The "Variables should not be self-assigned" PowerBuilder code rule states that variables should not be set to the same value they already contain. This means that any assignment statement that assigns a variable to itself should be avoided, as it is redundant and can lead to confusion and errors. Self-assignment can also lead to unexpected results, as the value of the variable may not be what was expected. For example, if a variable is assigned to itself within an if statement, the value of the variable may be changed even if the if statement condition is not met.

Display all the rules belongs to Oracle language.

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.

Bug Major All branches in a conditional structure should not have exactly the same implementation

The rule "All branches in a conditional structure should not have exactly the same implementation" states that when writing a PL/SQL code that contains a conditional structure (such as an IF statement), each branch of the conditional structure should have a different implementation. This means that the code should not be written in such a way that all of the branches have the same implementation, as this would be redundant and could lead to inefficient code. This rule helps to ensure that the code is written in an efficient and effective manner.

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.

Bug Critical Collections should not be iterated in FOR loops

The rule "Collections should not be iterated in FOR loops" in PL/SQL code means that collections should not be used in a FOR loop. Instead, collections should be iterated using a cursor, which is a looping construct that allows for the iteration of a collection. This rule is important because it ensures that the code is efficient and that it does not cause any unnecessary performance issues. Additionally, using a cursor allows for more flexibility when iterating over a collection, as it allows for the use of different types of iterators.

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.

Bug Critical COMMIT and ROLLBACK should not be called from non-autonomous transaction triggers

The rule "COMMIT and ROLLBACK should not be called from non-autonomous transaction triggers" states that when writing PL/SQL code, COMMIT and ROLLBACK should not be used in triggers that are not autonomous transactions. Autonomous transactions are transactions that are independent of the current transaction and can be committed or rolled back without affecting the current transaction. Non-autonomous transactions are transactions that are dependent on the current transaction and any changes made to them will affect the current transaction. Therefore, when writing PL/SQL code, it is important to ensure that COMMIT and ROLLBACK are not called from non-autonomous transaction triggers to avoid any unexpected changes to the current transaction.

Bug Critical COMMIT should not be used inside a loop

The rule "COMMIT should not be used inside a loop" states that the COMMIT statement should not be used inside a loop in PL/SQL code. This is because a COMMIT statement will cause the entire transaction to be committed, and any subsequent changes made within the loop will not be saved. Instead, the COMMIT statement should be used after the loop has been completed, so that all changes are committed at once.

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.

Bug Critical Constant declarations should contain initialization assignments

The rule "Constant declarations should contain initialization assignments" states that when declaring a constant in PL/SQL, it should be initialized with an assignment. This means that when a constant is declared, its value should be set immediately. This ensures that the constant is always initialized with a value and can be used in the code without any unexpected behavior.

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.

Bug Critical Constraints should not be applied to types that cannot be constrained

This rule states that constraints should not be applied to data types that cannot be constrained. This is because applying constraints to data types that cannot be constrained will result in an error. For example, if a constraint is applied to a data type such as a BLOB (Binary Large Object) or CLOB (Character Large Object), the constraint will not be enforced and an error will be thrown. Therefore, it is important to ensure that constraints are only applied to data types that can be constrained.

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.

Bug Critical DELETE and UPDATE statements should contain WHERE clause

The DELETE and UPDATE statements should contain a WHERE clause in order to limit the scope of the operation. Without a WHERE clause, the statement will delete or update all rows in a table, which is not usually the desired outcome. The WHERE clause should specify the criteria for the rows to be affected by the statement. This ensures that only the intended rows are affected and that other rows are not unintentionally modified.

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.

Vulnerability Critical DES or 3DES Used DES or 3DES Used is a rule for encrypting data using the Data Encryption Standard (DES) or Triple DES (3DES) algorithms. DES is an older encryption algorithm that uses a 56-bit key to encrypt data, while 3DES is a more secure algorithm that uses three 56-bit keys for encryption. Both algorithms are widely used for encrypting data, especially for financial and government applications.
Bug Major DML events clauses should not include multiple OF clauses

The rule "DML events clauses should not include multiple OF clauses" states that when using Data Manipulation Language (DML) events, only one OF clause should be used. This means that when writing DML events, the syntax should only include one OF clause. Multiple OF clauses can lead to syntax errors and unexpected results, so it is important to adhere to this rule when writing DML events.

SecurityWarning Critical Dynamically executing code is security-sensitive

The rule "Dynamically executing code is security-sensitive" in PL/SQL code means that code which is executed at runtime, rather than being compiled and stored in the database, can pose a security risk. This is because the code is not checked for errors or malicious code before it is executed, and so can potentially be used to gain access to sensitive data or perform malicious actions. As such, it is important to ensure that any code which is executed dynamically is properly checked and secured before it is executed.

Bug Critical END LOOP should be followed by a semicolon The END LOOP should be followed by a semicolon (;) rule in PL/SQL code states that the END LOOP statement must be followed by a semicolon (;) in order for the code to be valid and executable. This is because the END LOOP statement marks the end of a loop, and the semicolon (;) is used to terminate the statement. Without the semicolon (;), the code will not be valid and will not execute correctly.
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.

Vulnerability Critical Exceptions should not be ignored

The rule "Exceptions should not be ignored" in PL/SQL code means that any errors or exceptions that occur during the execution of the code should be handled properly. This means that the code should include appropriate exception handling blocks to catch any errors that may occur. The code should also include appropriate logging and error messages to ensure that any errors are properly recorded and reported. This rule is important to ensure that any errors that occur during the execution of the code are handled properly and do not cause any unexpected or undesired behavior.

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.

Bug Minor Explicitly opened cursors should be closed

The rule "Explicitly opened cursors should be closed" states that any cursors that have been explicitly opened in a PL/SQL block must be closed before the block is exited. This is important because it ensures that any resources associated with the cursor are released and that the cursor is no longer available for use. Failure to close an explicitly opened cursor can lead to unexpected behavior and errors when the block is executed. It is also important to note that cursors that are opened implicitly (i.e. not explicitly opened) do not need to be closed.

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.

Bug Critical FETCH ... BULK COLLECT INTO should not be used without a LIMIT clause

The FETCH ... BULK COLLECT INTO code rule states that the FETCH ... BULK COLLECT INTO statement should not be used without a LIMIT clause. This is because the FETCH ... BULK COLLECT INTO statement can be used to retrieve a large number of rows from a database table, and without a LIMIT clause, it could retrieve an excessive amount of data, which could cause performance issues. Therefore, it is important to always include a LIMIT clause when using the FETCH ... BULK COLLECT INTO statement to ensure that only the necessary amount of data is retrieved.

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.

Bug Critical FORALL statements should use the SAVE EXCEPTIONS clause

The FORALL statement in PL/SQL is used to execute a set of DML statements in a single call, and can improve performance when used correctly. The SAVE EXCEPTIONS clause should be used when using the FORALL statement to ensure that any exceptions encountered during the execution of the DML statements are saved and can be inspected later. This clause allows the user to identify which statements failed and why, and can be used to take corrective action if necessary.

Bug Critical FORMS_DDL('COMMIT') and FORMS_DDL('ROLLBACK') should not be used

The rule "FORMS_DDL('COMMIT') and FORMS_DDL('ROLLBACK') should not be used" states that the PL/SQL code should not use the FORMS_DDL('COMMIT') and FORMS_DDL('ROLLBACK') commands. These commands are used to commit or rollback changes to the database, and should not be used in PL/SQL code as they can cause unexpected results. Instead, the code should use the COMMIT and ROLLBACK commands, which are more reliable and provide better control over the database transactions.

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.

Bug Critical Functions should end with RETURN statements

The Pl_Sql code rule that "Functions should end with RETURN statements" states that all functions should be terminated with a RETURN statement. This RETURN statement should be the last line of code in the function and should return a valid value that is compatible with the function's return type. This ensures that the function returns the expected result and does not cause any unexpected errors.

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.

Bug Major Identical expressions should not be used on both sides of a binary operator

The Pl_Sql code rule "Identical expressions should not be used on both sides of a binary operator" states that when writing code, the same expression should not be used on both sides of a binary operator. This is because the expression on the left side of the operator will be evaluated first, and then the expression on the right side will be evaluated. If the same expression is used on both sides, the result of the evaluation will always be the same, and the code will not produce the desired result. This rule helps to ensure that code is written correctly and produces the desired results.

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.

Bug Major IF statement conditions should not evaluate unconditionally to TRUE or to FALSE

The IF statement condition should not evaluate unconditionally to TRUE or FALSE rule states that when writing an IF statement, the condition should not be written in a way that it will always evaluate to either TRUE or FALSE. This means that the condition should be written in a way that it can evaluate to either TRUE or FALSE depending on the data that is being evaluated. This is important in order to ensure that the IF statement will be able to evaluate the data accurately and provide the correct output.

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.

Bug Critical Improper constraint forms should not be used

The rule "Improper constraint forms should not be used" states that any PL/SQL code should not use any forms of constraints that are not supported by the language. This includes using constraints that are not supported by the language, such as using a non-standard syntax or using an unsupported type of constraint. This rule is important to ensure that the code is written correctly and is not prone to errors or unexpected behavior. Additionally, it helps to ensure that the code is compatible with other PL/SQL code and databases.

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.

Bug Critical Individual WHERE clause conditions should not be unconditionally true or false

The rule "Individual WHERE clause conditions should not be unconditionally true or false" states that each condition in a WHERE clause should be evaluated and not be predetermined as either true or false. This means that each condition should be checked against the data and not be assumed to be true or false without any evaluation. This helps to ensure that the results of the query are accurate and that the query is not returning incorrect results due to an assumption that a condition is true or false.

Bug Critical Insert statement values not including Non-Null Columns

The "Insert statement values not including Non-Null Columns" rule in PL/SQL states that when inserting values into a table, any non-null columns must be included in the insert statement. This means that any columns with a non-null constraint must be included in the insert statement, even if the value being inserted is NULL. If a non-null column is not included in the insert statement, an error will be thrown. This rule is important to ensure data integrity and accuracy in the database.

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.

Bug Major Jump statements should not be followed by dead code

The "Jump Statements Should Not Be Followed by Dead Code" rule states that when a jump statement (such as a GOTO, EXIT, or RETURN statement) is used, the code that follows should not be executed. This is because the jump statement will cause the program to jump to a different part of the code, and any code after the jump statement will not be executed. This can lead to unexpected results and can be difficult to debug. Therefore, it is best practice to avoid having dead code after a jump statement.

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.

Bug Major Loops with at most one iteration should be refactored

The "Loops with at most one iteration should be refactored" rule for PL/SQL code states that any loops that contain only one iteration should be replaced with simpler code. This is because loops are designed to execute a set of instructions multiple times, and a loop with only one iteration is redundant and can be replaced with simpler code. Refactoring loops with only one iteration can help improve code readability and maintainability, as well as reduce the amount of code needed to achieve the same result.

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.

Bug Major MLSLABEL should not be used

The rule "MLSLABEL should not be used" states that the PL/SQL code should not use the MLSLABEL keyword. This keyword is used to identify a label in the source code, which can be used to control the flow of the program. Instead, other methods such as IF-THEN-ELSE or CASE statements should be used to control the flow of the program. Using MLSLABEL can lead to unexpected results and should be avoided.

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.

Bug Critical NCHAR and NVARCHAR2 size in bytes The NCHAR and NVARCHAR2 size in bytes rule states that the size of NCHAR and NVARCHAR2 data types must be specified in bytes rather than characters. The maximum size of an NCHAR or NVARCHAR2 column is 2000 bytes. The number of characters that can be stored in an NCHAR or NVARCHAR2 column is dependent on the number of bytes specified for the column. For example, if the size of the column is specified as 10 bytes, then the maximum number of characters that can be stored in the column is 10 characters.
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.

Bug Major NULL should not be compared directly

The rule "NULL should not be compared directly" in PL/SQL code means that when comparing two values, the comparison should not be done directly with the NULL value. Instead, the IS NULL or IS NOT NULL operators should be used. This is because the comparison of two NULL values will always return NULL, which may not be the desired result. Using the IS NULL or IS NOT NULL operators will ensure that the comparison is done correctly and that the expected result is returned.

Bug Critical Nullable subqueries should not be used in NOT IN conditions

The rule "Nullable subqueries should not be used in NOT IN conditions" states that when using a NOT IN condition in a PL/SQL statement, the subquery should not return any null values. This is because when a subquery returns a null value, the NOT IN condition will always evaluate to false, even if the value being compared is not in the subquery. This can lead to unexpected results and should be avoided.

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.

Bug Major Output parameters should be assigned

The rule "Output parameters should be assigned" states that when writing PL/SQL code, any output parameters should be assigned a value before the code is executed. This ensures that the output parameters are set to the correct value and will be returned correctly when the code is executed. This is important for code readability and maintainability, as it allows the programmer to clearly see what values are being returned from the code. It also helps to prevent unexpected results, as any output parameters that are not assigned a value will return a NULL value.

Bug Critical Overridden Predefined Exceptions

The "Overridden Predefined Exceptions" rule in PL/SQL code states that when a predefined exception is raised, the associated error code and error message should be overridden with a user-defined error code and message. This allows for more precise control over the error handling process, as well as providing more meaningful error messages to the user. This rule also states that the user-defined error code should be unique, and should be used consistently throughout the code. Additionally, the user-defined error message should provide more information about the cause of the error, and should be written in a language that is easily understood by the user.

Bug Major PACKAGE BODY initialization sections should not contain RETURN statements

The rule "PACKAGE BODY initialization sections should not contain RETURN statements" states that the initialization sections of a PL/SQL package body should not contain RETURN statements. This rule is important because RETURN statements are used to terminate a PL/SQL program, and having them in the initialization sections of a package body could lead to unexpected behavior. Additionally, RETURN statements should only be used when necessary, as they can be difficult to debug.

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.

Bug Critical Pipelined functions should have at least one PIPE ROW statement and not return an expression

The rule states that when writing PL/SQL code for a pipelined function, the function must contain at least one PIPE ROW statement and should not return an expression. A PIPE ROW statement is used to return a row from a pipelined function, and an expression is a statement that evaluates to a single value. This rule ensures that the pipelined function is able to return multiple rows, as opposed to just a single value.

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.

Bug Critical Positional and named arguments should not be mixed in invocations

The rule "Positional and named arguments should not be mixed in invocations" states that when invoking a PL/SQL procedure or function, all arguments should either be passed in using their position in the argument list, or all arguments should be passed in using their named parameters. Mixing positional and named arguments in the same invocation is not allowed.

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.

Bug Critical RAISE_APPLICATION_ERROR should only be used with error codes from -20,000 to - 20,999

The RAISE_APPLICATION_ERROR code rule states that the RAISE_APPLICATION_ERROR command should only be used with error codes that range from -20,000 to -20,999. This command is used to raise an exception and return an error message to the user. The error message should be meaningful and provide information about the cause of the error. This code rule ensures that the error codes used are specific and meaningful, so that the user can easily understand the cause of the error.

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.

Bug Major Related IF / ELSIF statements and WHEN clauses in a CASE should not have the same condition

The rule related to IF / ELSIF statements and WHEN clauses in a CASE states that they should not have the same condition. This means that the conditions used to evaluate the IF / ELSIF statements and WHEN clauses should be distinct from each other. This ensures that the CASE statement is properly evaluated and that the correct result is returned. Having the same condition for both the IF / ELSIF statements and WHEN clauses can lead to unexpected results and should be avoided.

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.

Bug Major ROWNUM should not be used at the same query level as ORDER BY

The rule "ROWNUM should not be used at the same query level as ORDER BY" states that the ROWNUM pseudo-column should not be used in the same query as the ORDER BY clause. This is because the ROWNUM pseudo-column is assigned to each row before the ORDER BY clause is applied, so the results of the query may not be consistent. Therefore, it is recommended to use the ORDER BY clause before the ROWNUM pseudo-column is applied.

Bug Critical Scale should not be specified for float types

The Pl_Sql code rule "Scale should not be specified for float types" means that when defining a float type in Pl_Sql, the scale (the number of digits after the decimal point) should not be specified. This is because float types are designed to store numbers with a variable number of digits after the decimal point, and specifying a scale would limit the number of digits that can be stored.

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.

Vulnerability Critical Sensitive SYS owned functions should not be used

The rule "Sensitive SYS owned functions should not be used" in PL/SQL code means that functions owned by the SYS user should not be used in PL/SQL code. These functions are considered sensitive because they can have a significant impact on the system, and can be used to access sensitive information. Therefore, it is important to ensure that these functions are used only when absolutely necessary, and with the proper security measures in place.

Vulnerability Critical SHA-1 and Message-Digest hash algorithms should not be used in secure contexts

The rule "SHA-1 and Message-Digest hash algorithms should not be used in secure contexts" means that these algorithms should not be used when data security is a priority. SHA-1 and Message-Digest are both hashing algorithms, which are used to generate a unique value (or "hash") from a given set of data. These hashes can be used to verify the integrity of data, but they are not considered secure enough for use in secure contexts. As such, they should not be used when security is a priority.

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.

Bug Critical String variables with no Size specification

When declaring string variables with no size specification, the maximum size of the string is determined by the database. The maximum size of the string will depend on the database's configuration and the data type of the string. The maximum size of the string can be determined by querying the database for the maximum length of the data type. For example, if the string is of type VARCHAR2, the maximum size of the string can be determined by querying the database for the maximum length of VARCHAR2.

Bug Major Strings should only be moved to variables or columns which are large enough to hold them

This rule states that when using PL/SQL code, strings should only be stored in variables or columns that are large enough to contain them. This is important to ensure that the data is not truncated and that the code runs correctly. It is also important to consider the size of the string when allocating memory for the variable or column, as this can affect performance.

Bug Critical SYNCHRONIZE should not be used

The SYNCHRONIZE rule states that the SYNCHRONIZE keyword should not be used in PL/SQL code. This keyword is used to ensure that all transactions are synchronized with the database, and can cause performance issues if used incorrectly. To avoid this, developers should use other methods to ensure that transactions are properly synchronized with the database. This could include using the COMMIT command, or using the DBMS_LOCK package.

Bug Critical Syntax Errors

A syntax error in PL/SQL code occurs when the code does not follow the rules of the PL/SQL language. This type of error can be caused by incorrect spelling, incorrect punctuation, incorrect capitalization, or incorrect use of reserved words. Syntax errors can prevent the code from being executed, and can cause the code to produce unexpected results. In order to avoid syntax errors, it is important to read and understand the PL/SQL language and to follow the rules of the language when writing code.

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.

Bug Critical The number of variables in a FETCH statement should match the number of columns in the cursor

The rule states that the number of variables in a FETCH statement should match the number of columns in the cursor. This means that when a FETCH statement is used to retrieve data from a cursor, the number of variables used to store the data must be equal to the number of columns in the cursor. This ensures that all the data in the cursor is retrieved and stored in the correct variables. Failure to do so may result in data loss or incorrect data retrieval.

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.

Bug Major The result_cache hint should be avoided

The result_cache hint should be avoided as it can lead to unexpected results and performance issues. This hint is used to force the query optimizer to cache the result set of a query, which can lead to incorrect results if the underlying data has changed since the query was executed. Additionally, the result set can become stale if the underlying data is updated, leading to performance issues. Therefore, it is recommended to avoid using the result_cache hint and instead use other methods such as materialized views to improve query performance.

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.

Bug Major Unary prefix operators should not be repeated

The rule "Unary prefix operators should not be repeated" states that when using unary prefix operators in PL/SQL code, the same operator should not be used multiple times in succession. For example, if the operator is "-", then "- -" should not be used. This is because the double operator would be redundant and could lead to confusion. Additionally, it could lead to errors in the code. Therefore, it is best practice to only use unary prefix operators once in succession.

Bug Critical Uninitialized NOT NULL Variables

The Uninitialized NOT NULL Variables rule states that all NOT NULL variables must be initialized before use. This rule ensures that all variables are properly initialized and that the code does not attempt to use a variable that has not been initialized. This rule helps to prevent errors and unexpected behavior in the code. It also helps to ensure that the code is more readable and maintainable.

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.

Bug Critical Unsupported Syntax Errors

Unsupported Syntax Errors are errors that occur when a PL/SQL code contains syntax that is not supported by the version of the PL/SQL compiler being used. These errors are usually caused by using a feature that is not available in the version of the compiler being used. Examples of unsupported syntax errors include using a feature that was introduced in a later version of the compiler, or using a feature that has been deprecated in the current version of the compiler.

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.

Bug Major VARCHAR2 and NVARCHAR2 should be used

The rule "VARCHAR2 and NVARCHAR2 should be used" states that the VARCHAR2 and NVARCHAR2 data types should be used when creating columns in a database table. These data types are used to store character strings, and are the preferred data types for storing character strings in Oracle databases. VARCHAR2 is used for storing strings of up to 4000 characters, while NVARCHAR2 is used for storing strings of up to 2000 characters. Both data types are used for storing character strings, but NVARCHAR2 should be used when the data is Unicode-encoded, as it is more efficient than VARCHAR2 for storing Unicode-encoded data.

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.

Bug Major Variables and columns should not be self-assigned

The rule "Variables and columns should not be self-assigned" in PL/SQL code means that variables and columns should not be assigned to themselves. This is a best practice to follow in order to avoid errors and confusion. Self-assigning variables and columns can lead to unexpected results, and can be difficult to debug. It is best to assign variables and columns to other values or results from other operations.

Bug Critical Variables Declared multiple times in nested scope

When using PL/SQL code, it is important to remember that variables declared multiple times in nested scope will override the original declaration. This means that if a variable is declared in an outer scope and then again in a nested scope, the nested declaration will take precedence. This can lead to unexpected results if the programmer is not aware of the precedence rules. It is important to ensure that variables are only declared once in a given scope to avoid any potential issues.

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.

Bug Major WHERE clause conditions should not be contradictory

The rule "WHERE clause conditions should not be contradictory" states that when writing a WHERE clause in a PL/SQL statement, the conditions should not contradict each other. This means that the conditions should not be mutually exclusive, as this will cause the statement to return an empty result set. For example, the following statement would not be valid: WHERE x = 1 AND x = 2. This statement is contradictory because it is impossible for x to be both 1 and 2 at the same time.

Display all the rules belongs to SqlServer language.

Category Severity Name Description
Maintainability Major @@IDENTITY should not be used

The code rule "@@IDENTITY should not be used" states that the global variable @@IDENTITY should not be used in SQL Server code. This variable is often used to retrieve the last identity value generated in the current session, but it can be unreliable and lead to unexpected results. Instead, the SCOPE_IDENTITY() function should be used to retrieve the last identity value generated in the current scope.

Maintainability Critical A primary key should be specified during table creation

The rule that a primary key should be specified during table creation ensures that each record in a database table is uniquely identified. This is done by assigning a unique value, or combination of values, to each record. This makes it easier to locate and update individual records, as well as ensuring data integrity and preventing duplicate records. Specifying a primary key during table creation also helps to improve query performance by allowing the database engine to quickly identify and retrieve records.

Bug Major All branches in a conditional structure should not have exactly the same implementation

The rule "All branches in a conditional structure should not have exactly the same implementation" states that when a conditional structure is used in SQL Server code, the branches should not have identical implementations. This means that each branch should have a unique implementation that is tailored to the specific conditions of that branch. This helps to ensure that the code is efficient and that it produces the desired results. Additionally, this rule helps to prevent potential errors or unexpected behavior that could occur if the same implementation were used for all branches.

Maintainability Major ANSI_NULLS, ANSI_PADDING and CONCAT_NULL_YIELDS_NULL should not be configured The ANSI_NULLS, ANSI_PADDING and CONCAT_NULL_YIELDS_NULL code rules indicate that the SQL Server should not be configured to use these settings. ANSI_NULLS defines how to handle comparisons involving NULL values. When set to ON, two NULL values are considered equal. When set to OFF, two NULL values are considered unequal. ANSI_PADDING defines how to handle trailing spaces in character data. When set to ON, trailing spaces are retained. When set to OFF, trailing spaces are removed. CONCAT_NULL_YIELDS_NULL defines how to handle the concatenation of NULL values. When set to ON, the result of the concatenation is NULL. When set to OFF, the result of the concatenation is an empty string. For optimal performance, it is recommended that these settings not be configured as they can lead to unexpected results and can affect the performance of the SQL Server.
Maintainability Minor