Release Notes 24.0.4

CodeScan On-Premises

Release Notes 24.0.4

Release Date: April 2024

Rules & Fixes

This update introduces several new rules and bug fixes for current rules. This includes:

1. Improved the CodeScan parser as it relates to Visual Force. Specifically, the parser had some issues recognizing parts of Aura code (for example, with components (cmp), the parser was unable to recognize divs and spans across multiple lines). With this release, we have corrected these issues and verified that the Visual Force parser for .cmp, vf, xml, and .page files are all parsed properly. Further, CodeScan users can successfully see these issues after analysis.

2. Fixed a NullPointerException with the Apex rule “Null Coalescing Operator.”

3. Apex Rules:

• Duplicate method implementations: Methods should not share the same implementations. To prevent duplication and confusion, avoid using two methods with identical implementations.

• Code length: Lines should not be too long in APEX. Limiting the length of code lines enhances code clarity and readability by reducing complexity and improving quick understanding.

• System.runAs to test user permissions: To ensure accurate and realistic testing of user permissions, it is crucial to utilize System.runAs during test execution, ensuring logic is tested in the same context in which it will run.

• Relative Salesforce URLs: Salesforce pages should use relative URLs, as code using absolute URLs for Salesforce pages will break in different environments.

• “If ... else if” should have “else” case: Include a default case using an "else" statement at the end of "if" and "else if" clauses to handle all conditions and provide code clarity.

• Limit case clauses in switch statements: Using a large number of case clauses in switch statements creates complex, difficult-to-read code.

• Avoid Identical Expressions on Both Sides of a Binary Operator: When both sides of a binary operator have identical values, the condition will always give the same result.

• Avoid Sending Emails in Loops: Avoid using Messaging.sendEmail within loops to prevent exceeding Salesforce governor limits and to enhance application performance.

• Avoid duplicate conditions in "if"/"else if" and "switch": When the same conditions are used in statements like "if"/"else if" and "switch", it can lead to duplicate or dead code.

• API Versions 7.0 through 20.0 Retirement: The retirement of older Salesforce Platform API versions (7.0 through 20.0) after the Summer '22 release is a critical step to ensure the continued smooth operation of Salesforce applications.

• Avoid using methods getDescribe and getMap inside Loops: The ‘getDescribe’ and ‘getMap’ methods typically involve fetching metadata information for objects and fields. Invoking them inside loops can result in unnecessary overhead.

1. Assertion Rules:

• Use Assert.areEqual instead of Assert.isTrue: This rule detects Unit test assertions in object references equality. Instead of using Assert.isTrue as an equality check, these assertions should be made by more specific methods, like Assert.areEqual.

• Use Assert.isTrue instead of Assert.areEqual: When asserting a value that is the same as a Boolean literal, use Assert.isTrue, instead of Assert.areEqual.

• Use Assert Equals Instead of Boolean Equality Assertion: This rule detects unit test assertions in object references equality. Instead of using Assert.isTrue combined with "==" as an equality operator, these assertions should be made by more specific methods, like Assert.areEqual (expected, actual).

• Unit Assertions should include a Message: Unit assertions should include a message. In other words, use the three-argument version of Assert.areEquals(), not the two-argument version.

• Unit Test Method Contains Too Many Asserts: Unit tests should not contain too many asserts. Many asserts are indicative of a complex test, for which it is harder to verify correctness. Consider breaking the test scenario into multiple, shorter test scenarios. Customize the maximum number of assertions used by this Rule to suit your needs.

• Non-Unit Test Methods Should Not Contain Asserts: Asserts should only be used in test methods.

• Misuse of Assert Class: Assert Class can be misused if not applied correctly. To ensure the correctness of our code and avoid common pitfalls, establish best practices for its usage.

• Use Messages in Assert Statements: Ensure that messages are included when using the assert method with the message parameter to improve code quality and make it easier to identify the cause of failures during testing and debugging.

• Consider Using Assert in place of System.Assert: This new class aims to enhance the readability and maintainability of test code for developers. It is preferable to use Assert in your tests instead of older System.Assert methods.

1. LWC Rules:

• Enable Salesforce Lightning Web Security (LWS): Enabling LWS ensures that the Lightning components within our Salesforce instance are executed in a secure and controlled environment, reducing the risk of potential security vulnerabilities.

1. SF Meta:

• Adopt the ICU Locale Formats instead of JDK locale formats: Salesforce is retiring the JDK locale formats with the Spring ’24 release. ICU is the new standard enforced in API version 45. Make sure your custom code does not use JDK locale formats and instead uses locale-neutral methods.

• Set Flows to Auto Layout: Implementing auto-layout for your flows helps designers modify layouts more quickly, allowing them to iterate on their designs with greater speed. It ensures elements are perfectly aligned and evenly spaced, improving readability in complex Flows.

• Potential Overuse of Rollup Summaries: Ensure compliance with Salesforce's limit of 25 roll-up summary fields per object to prevent potential issues arising from exceeding Salesforce platform limits.

1. Improvement was provided on how to fix for the "Deserializing JSON is Security Sensitive" rule.

2. We provided a fix on the "sf:AvoidUsingHardCodedId" rule not detecting hard-coded IDs as expected.

3. Wrongly identified violations in specific scenarios were fixed for the "Comments are Required" rule.

4. The rule "sf:AvoidPublicFields" was updated to exclude public fields with the @InvocableVariable annotation.

5. We provided a fix for the rule's missing root element in "RuleSet."

6. We provided a fix for the "Consider removing inactive flows" rule not working correctly.