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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.