Appendix F.4: Custom Code Analyzer Regex Rules¶

A regex rule is a pattern that the regex engine of Salesforce Code Analyzer matches against the text of a file. It sees text, not syntax, so it is the right tool where no engine exposes the thing to check, and a stopgap where PMD will expose it later. Where a PMD rule written in Java can make the check, this reference uses that instead (Choosing Between Them).

A regex rule is defined in code-analyzer.yml itself, under engines.regex.custom_rules, with its pattern, the file extensions it scans, a description, a violation message, a severity, and tags. There is no separate rules file: the YAML is both the definition and the configuration, so a regex rule runs under Code Analyzer only, and not under PMD on its own. The sample code-analyzer.yml carries the {N} custom regex rules of this reference. This page describes them, and the sample is the definition. The engine itself is described in Appendix E.

The Rules¶

The rules are listed most severe first, then by name. Each rule name is an anchor that a standard can link to. Which standard each rule enforces is in Appendix F.6.

Every rule carries a severity in its definition, and the Severity Levels say what each severity means for the pipeline. The {N} rules at severity 5 report a comment that the team has chosen to leave for now; the seven at severity 2 and 3 report something to fix before the pull request merges, and the one at severity 4 reports a page or component with no header comment.

Using and Changing the Rules¶

These rules are a starting point, as the PMD rulesets are (Using and Changing the Ruleset). An organisation changes a rule in its definition: the severity, the pattern, the file extensions it scans, and the message are all there, and there is no property beside them. A rule the organisation does not want is removed from the file, or switched off with disabled: true under rules.regex. A rule of the organisation's own is a new entry under engines.regex.custom_rules, with the same parts. Regenerating the file with sf code-analyzer config --config-file code-analyzer.yml --output-file code-analyzer.yml keeps the block (Appendix E).

A change to a regex rule goes through the same change process as a change to a ruleset: a pull request, a review, and a sign-off, with the file protected by CODEOWNERS so that only the governance team can change it (Repository Structure).

Rules That Ship With the Regex Engine¶

The regex engine also ships {N} rules of its own, every one tagged Recommended, so Code Analyzer runs each unless the sample code-analyzer.yml disables it. {N} run:

• AvoidOldSalesforceApiVersions (source), at severity 2. The standard it enforces, and the rule recommended in its place, are in Metadata Standards: API Version.
• AvoidGetHeapSizeInLoop, at severity 2: a call to Limits.getHeapSize() inside a loop (Apex: CPU Time and Heap).
• MinVersionForAbstractVirtualClassesWithPrivateMethod, at severity 2: an abstract or virtual class with a private method below API 61.0 (Apex: API Version).
• AvoidTermsWithImplicitBias, at severity 4, one above the 5 it ships at: a term that carries an implicit bias, anywhere in the code (Principles: Inclusive for Everyone).
• NoTrailingWhitespace, at severity 5, for the developer's information: a space or a tab at the end of a line, or a line of nothing but whitespace. Prettier removes both from every file it formats, and the Prettier gate runs before Code Analyzer on every pull request, so a report is a sign that Prettier did not format the file (Apex: Formatting).

floor(((year - 2007) * 12 + month - 2) / 4)

{N} is disabled, with disabled: true in the sample code-analyzer.yml. NoMixedIndentation reports any line that is indented with a tab and then a space. Every continuation line of an ApexDoc comment inside a tab-indented class is such a line (a tab, a space, and an asterisk), so the rule reports every documented class written to these standards, which require both tabs and ApexDoc; and Prettier sets the indentation of every file before the gate runs.