# Defining matching patterns

## Defining matching patterns for files <a href="#for-files" id="for-files"></a>

To define path-matching patterns, you can use the following wildcards:

* `*` matches zero or more characters (not including the directory delimiter, `/`).
* `**` matches zero or more directory segments within the path.
* `?` matches a single character (not including the directory delimiter, `/`).

A file path definition is either relative to the sonar.projectBaseDir property (which is by default the directory from which the analysis was started; for more information, see [analysis-parameters](https://docs.sonarsource.com/sonarqube-server/analyzing-source-code/analysis-parameters "mention")) or absolute.

The table below shows path-matching pattern examples.

| **Matching pattern**               | **Definition**                                                                                                                     |
| ---------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| `**/*.css`                         | `<anyDirectory>/<anyFileName>.css`                                                                                                 |
| `**/*Bean.java`                    | <p><code>\<anyDirectory>/\<anyString>Bean.java</code></p><p>Example: <code>org/sonar.api/MyBean.java</code></p>                    |
| `**/*Bean?.java`                   | <p><code>\<anyDirectory>/\<anyString>Bean\<singleCharacter>.java</code></p><p>Example: <code>org/sonar.api/MyBean1.java</code></p> |
| `org/sonar/*`                      | `org/sonar/<anyFile>`                                                                                                              |
| `org/sonar/**` or `org/sonar/**/*` | <p><code>org/sonar/\<anyDirectory>/\<anyFile></code></p><p>Example: <code>org/sonar/api/test/Bean.java</code></p>                  |

## Defining matching patterns for coding rules <a href="#for-coding-rules" id="for-coding-rules"></a>

To define matching patterns for coding rules, use the following syntax:

`<ruleRepository>:<searchString>`

Where:

* ruleRepository: is the identifier of the rule repository\
  Examples: SonarQube java (identifier: java) or Security SonarAnalyzer PHP (identifier: phpsecurity), etc.\
  You can use the wildcard pattern \* (any string) to define the rule repository.
* searchString: is any search string present in the rule key or in the rule name

The matching pattern means that any rule:

* of the specified repository
* whose name or key contains the specified search string

is a match.

<details>

<summary>Rule-matching pattern examples</summary>

| **Rule-matching pattern** | **Description**                      |
| ------------------------- | ------------------------------------ |
| `css:S4655`               | Rule ID s4655 in the repository css. |
| `*:S4655`                 | Rule ID s4655 in any repository.     |
| `*`                       | All rules.                           |

</details>

<details>

<summary>Identifying the repository, name, and key of a rule</summary>

1. Go to **Rules** in the top navigation bar.
2. Use the filter on the left to search for a rule. The search results are displayed in the right panel.
3. In the search results, click the rule you want to view. The rule opens and you can see the rule parameters such as: rule name, rule ID, analysis scope, rule repo, effort, software qualities impacted, and code attribute.

<figure><img src="https://2744305742-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F3VWSqvZ4eaBLWvA6epdv%2Fuploads%2FLZbFHOXN1vOOa3hWcfBj%2Frule%20(1).png?alt=media&#x26;token=b67aaaf0-3d9b-47b4-95d6-4fa2b285e61b" alt="Rule details"><figcaption></figcaption></figure>

</details>