Salesforce Code Review tools

These rules will generally enforce the best approaches followed as per the Salesforce app development guidelines.
• ApexUnitTestClassShouldHaveAsserts: Test class methods having an assert statement to verify the test results is as per the design.
• ApexUnitTestShouldNotUseSeeAllDataTrue: Test class shouldn’t use the data from the org, instead test data must be created.
• AvoidLogicInTrigger: Trigger logic must be written in the separate handler classes.
• UnusedLocalVariable: A variable if declared must be used in the code somewhere.

The rules which enforces a specific coding style that has been considered as a standard.
• ClassNamingConventions: Rule is to have the name of the class in pascal case.
• FieldDeclarationsShouldBeAtStart: All the field declarations to be at the start of the class.
• FieldNamingConventions: Fields should be named in camel case.
• ForLoopsMustUseBraces: The for loop should be opened and closed with braces.

These rules help in identifying the design issues.
• AvoidDeeplyNestedIfStmts: Avoid using deeply nested if statements in the logic.
• ExcessiveClassLength: A class shouldn’t be burdened with excessive amount of functionalities.
• ExcessiveParameterList: A method in the class shouldn’t include too many parameters.
• TooManyFields: An object shouldn’t have too many custom fields created.

They are rules related to code documentation.
• ApexDoc: It talks about the class level and method level comments to be added in the code for better readability.

They are rules to detect portion of code that are either broken, extremely confusing or prone to runtime errors.
• ApexCSRF: Not using DML operations in the apex class constructors or initializers to avoid security alert.
• AvoidDirectAccessTriggerMap: Avoid directly accessing the record using trigger events like Trigger.new or Trigger.old.
• AvoidHardcodingId: Avoid hardcoding of the record ids or parameter ids in the code.
• EmptyCatchBlock: The exception catch statement should have an error logging mechanism in place.

They are rules to raise a flag on suboptimal code which will lead to performance issues.
• AvoidDmlStatementsInLoops: Avoid DML statements within for loops and while loops to avoid hitting the governor limits.
• AvoidSoqlInLoops: Avoid using SOQL within loops to query records from the object.
• AvoidSoslInLoops: Not to use the SOSL within loops as well to avoid hitting governor limits.

These rules highlight the probable security flaws in the code.
• ApexBadCrypto: The rule makes sure you are using randomly generated IVs and keys for Crypto calls.
• ApexCRUDViolation: The rule validates you are checking for access permissions before a SOQL/SOSL/DML operation.
• ApexSOQLInjection: This detects the usage of untrusted / unescaped variables in DML queries.
• ApexSharingViolations: It detects classes declared without explicit sharing mode if DML methods are used.

• VfCsrf: Avoid calling VF action upon page load as the action becomes vulnerable to CSRF.
• VfUnescapeEl: Avoid unescaped user-controlled content in EL as it results in XSS

- URLs of Salesforce pages should be relative and not absolute
- DML statements should not be used inside loops.
- Record IDs should be hardcoded.
- Triggers should process records in bulk.
- Variables should not be self-assigned.

- Cognitive Complexity of functions should not be too high.
- Switch statements should have when else clauses.
- String literals should not be duplicated.
- SeeAllData should be false in test methods.
- Messages should not be hardcoded.

- Sharing level should be specified in Apex classes with SOQL/SOSL queries or DML statements.
- Credentials should not be hard-coded.

- Executing SOQL, SOSL or DML queries without sharing or with sharing
- Using hardcoded IP addresses.

CodeScan maintains the quality of the code throughout development while allowing you to customize own metrics of quality gates.

It provides the ability to track the amount of technical debt in the projects to plan the refactoring effort.

Reduces significant amount of time spent in manual apex review.

It makes sure the code is secure with selection of security rules on CWE and OWASP standards

Automation of the reviews results in cleaner code in production and thus increase productivity.

It applies coding rules and standards and standardizes the way we look at code and peer review process.

S4 for Salesforce reviews the configurations of a Salesforce org and identifies flaws

S4 uses a robust client-side static code analysis engine to create call flows to identify CRUD/FLS flaws. It uses data flow analysis to associate Visualforce components to their associated controllers.

S4 uses white-box fuzzing to rapidly identify injection flaws within Force.com code. All vulnerabilities identified during run-time testing contain Proof of Concept (PoC) exploits. This ensures there are no false positives.

S4 launches the custom fuzzer in the installed organization and can be scaled out to as many organizations as needed. All code analyzed remains within the organization preserving intellectual property of the code base.