---
schema_version: "1"
id: 33e1cd30602cda7133992547c0dbaf7d8e00d4d9b83e169edcbac0678a5b3ae6
title: Regex
collection: developer
version: current
locale: en-us
portal_url: https://docs.salesforce.com/developer/current/en-us/code-analyzer/salesforce-code-analyzer/guides/engine-regex.md
canonical_url: https://developer.salesforce.com/docs/platform/salesforce-code-analyzer/guide/engine-regex.html
source_site: developer.salesforce.com
content_type: documentation
content_hash: 4250898d6fe74a27fe334408fe993b7ac865cee040a554c454698c013b8064a7
products:
- Salesforce Code Analyzer
---
# Regex
The Regex engine is new in Code Analyzer v5. The engine uses regular expressions (regex) to search your code base for patterns. This engine is perfect for a quick initial check of your code base to search for specific text or strings. It’s also useful to search for patterns in your code comments; some engines, such as PMD, ignore comments. But it’s a blunt tool: if you need more nuance, such as finding actual coding violations, use a different engine.
The true power of this engine comes with the ease of adding new rules of your own. If you have regular expression patterns that you want to test against your code, you can easily provide these patterns to your Code Analyzer configuration file to be automatically included as rules. You can then run these rules alongside all of the other rules that Code Analyzer offers.
## Available Regex Rules
Run this command to view the list of available Regex rules:
```bash
sf code-analyzer rules --rule-selector regex --view detail
```
See [Regex Rules Reference](https://developer.salesforce.com/docs/platform/salesforce-code-analyzer/guide/rules-regex.md) for additional details.
For information on how to modify rule settings, such as their severity or tags, see [Customize Your Configuration](https://developer.salesforce.com/docs/platform/salesforce-code-analyzer/guide/config-custom.md).
## Add Custom Regex Rules
Adding custom Regex rules to Code Analyzer is easy: simply add a `custom_rules` option to the `regex` engine section of the `code-analyzer.yml` and specify the required and optional Regex rule properties. The basic pattern looks like this:
```yaml
engines:
regex:
custom_rules:
"RuleName":
property: value
property: value
"OtherRuleName":
property: value
property: value
```
Here are all the properties you can configure:
| Property Name | Required? | Description | Default Value | Possible Values |
| ------------------- | --------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- |
| `regex` | Yes | The regular expression that triggers a violation when matched against the contents of a file. | Not supported | |
| `file_extensions` | Yes | The extensions of the files in your workspace that you want to test the regular expression against. | Not supported | |
| `description` | Yes | A description of the rule's purpose and what it does. | Not supported | |
| `violation_message` | No | The message that's emitted when a rule violation occurs. Write the message to help the user understand the violation, and if possible, how to fix it. | `A match of the regular expression {regex} was found for rule {rule_name}: {description}` | |
| `severity` | No | The severity level to apply to this rule by default. | 3 (`Moderate`) | 1 or `Critical`, 2 or `High`, 3 or `Moderate`, 4 or `Low`, 5 or `Info` |
| `tags` | No | The string array of tag values to apply to this rule by default. | `['Recommended']` | |
| `ignore-regex` | No | Exclude safe patterns from violations. | Not supported | |
In this example, the name of the new rule is `NoTodoComments`. The Regex expression searches for all case-insensitive occurrences of the string `TODO` in Apex files in your workspace; specifically, the files must have the extension `.apex`, `.cls`, or `.trigger`. The severity of this violation is `Info` and its tag is `TechDebt`.
```yaml
engines:
regex:
custom_rules:
"NoTodoComments":
regex: /\/\/[ \t]*TODO/gi
file_extensions: [".apex", ".cls", ".trigger"]
description: "Prevents TODO comments from being in apex code."
violation_message: "A comment with a TODO statement was found. Please remove TODO statements from your apex code."
severity: "Info"
tags: ["TechDebt"]
```
This custom regex rule detects the hardcoded APIs while ignoring the false positives.
```yaml
engines:
regex:
custom_rules:
name: HardcodedAPIKeys
pattern_regex: "api[_-]?key['\"]?\\s*[:=]\\s*['\"][a-zA-Z0-9]{20,}['\"]"
regex_ignore: "test|mock|example|dummy|fake"
severity: 1
message: "Hardcoded API key detected"
```
After you add this rule to the `code-analyzer.yml` file, you refer to it when running the `rules` and `run` CLI commands like this:
```bash
sf code-analyzer rules --rule-selector regex:NoTodoComments --view detail
sf code-analyzer run --rule-selector regex:NoTodoComments --view detail
```
Also, as a convenience, Code Analyzer automatically adds the `Custom` tag to custom rules. Use this command to see all the custom Regex rules; your new rule should be in the list:
```bash
sf code-analyzer rules --rule-selector regex:Custom
```
## Regex Configuration Reference
You can configure the Regex engine with the settings listed in this table. See [Customize the Configuration](https://developer.salesforce.com/docs/platform/salesforce-code-analyzer/guide/config-custom.md) for details on how to apply the settings.
| Field | Type | Description |
| --- | --- | --- |
| `disable_engine` | boolean | Whether to turn off the 'regex' engine so that it is not included when running Code Analyzer commands. Default value is `false`. |
| `custom_rules` | object | Custom rules to be added to the 'regex' engine of the format custom_rules.{rule_name}.{rule_property_name} = {value} where: - {rule_name} is the name you would like to give to your custom rule
- {rule_property_name} is the name of one of the rule properties. You may specify the following rule properties:
- 'regex' - The regular expression that triggers a violation when matched against the contents of a file.
- 'regex_ignore' - [Optional] The negative pattern - matches that also match this pattern will be excluded.
- This allows you to exclude false positives by specifying patterns that should NOT be flagged.
- Example: To match email headers with user input but exclude 'validatedMessageId':
- regex: /(To\|From):\\s*\\$\\([^)]+\\)/gi
- regex_ignore: /\\$\\(\\s*validatedMessageId\\s*\\)/gi
- 'file_extensions' - The extensions of the files that you would like to test the regular expression against.
- 'description' - A description of the rule's purpose
- 'violation_message' - [Optional] The message emitted when a rule violation occurs.
- This message is intended to help the user understand the violation.
- Default: 'A match of the regular expression {regex} was found for rule {rule_name}: {description}'
- 'severity' - [Optional] The severity level to apply to this rule by default.
- Possible values: 1 or 'Critical', 2 or 'High', 3 or 'Moderate', 4 or 'Low', 5 or 'Info'
- 'tags' - [Optional] The string array of tag values to apply to this rule by default.
Default value is `{}`.
---- [Example usage]: ---------------------
engines:
regex:
custom_rules:
"NoTodoComments":
regex: /\\/\\/[ \\t]*TODO/gi
file_extensions: [".apex", ".cls", ".trigger"]
description: "Prevents TODO comments from being in apex code."
violation_message: "A comment with a TODO statement was found. Please remove TODO statements from your apex code."
severity: "Info"
tags: ["TechDebt"]
"DataWeaveEmailHeaderInjection":
regex: /(To\|From\|Subject):\\s*\\$\\([^)]+\\)/gi
regex_ignore: /\\$\\(\\s*validatedMessageId\\s*\\)/gi
file_extensions: [".dwl"]
description: "Detects user input in email headers, excluding validated IDs."
severity: "Critical"
tags: ["Security"]
-------------------------------------------
|