<a id="regular-expressions"></a>
<a id="diagnostics-regex"></a>
# Regular Expressions

Many TrialGrid Diagnostics have settings to exclude objects from findings for a project. These exclusions can use regular expressions. Some Diagnostics also use them the other way round, to say which objects are correctly named. A good introduction and tutorial for learning more about regular expressions is here: [https://regexone.com/](https://regexone.com/) and you can test the regular expressions used by TrialGrid with the [https://regex101.com/](https://regex101.com/) or [https://pythex.org/](https://pythex.org/) websites.

<a id="regular-expression-examples"></a>
## Regular Expression examples

To exclude all objects starting with 'PR' and ending with 'DT':

```
^PR.*DT$'
```

To exclude all objects containing the text 'PROJECT':

```
^.*PROJECT.*
```

To exclude all objects containing the text 'PROJECT' or the text 'LIBRARY' followed by one or more digits:

```
^.*(PROJECT|LIBRARY)\d+
```

ie. the above will match 'Project1' and 'LIBRARY0123' but not 'PROJECT'

Regular expressions used in Diagnostic settings are case-insensitive.

<a id="saying-which-names-are-correct"></a>
## Saying which names are correct

The Diagnostics which check that Field OIDs follow a naming convention have a Regular Expression setting as well as their Prefix, Suffix and Contains settings. Use it when the names you want to allow are a shape rather than a fixed piece of text.

For example, to accept label Field OIDs which end in '_LBL' followed by any number of digits, so that 'AE_LBL', 'AE_LBL1' and 'AE_LBL999' are all allowed:

```
_LBL\d*$
```

A Prefix or Suffix setting cannot express that, because the number of digits is not fixed.

Enter one expression per line. An OID passes the check if it matches any one of the lines. Where a Prefix, Suffix or Contains value is also set, the OID has to satisfy every setting, not just one of them. Leave the setting blank to turn it off.

When a Regular Expression is set, a finding does not offer a corrected OID to fix with, because there is no way to work out a name that is certain to match an expression.

Avoid nesting one repeat inside another. An expression such as:

```
^([A-Z0-9]+_?)+_LBL$
```

has to try a very large number of ways to split a Field OID that does not match, and the time it takes doubles with every extra character in the OID. On the long OIDs a study can hold, the Diagnostic runs until it reaches its time limit and reports that instead of its findings. Write the same rule without the nesting:

```
^[A-Z0-9_]+_LBL$
```

<a id="wildcards-in-matrix-oid-settings"></a>
## Wildcards in Matrix OID settings

The Diagnostics which check a Matrix accept a wildcard in the Matrix OID instead of a regular expression. A `*` at the end matches any OID starting with the characters before it, and a `*` at the start matches any OID ending with the characters after it:

```
UNIQUE*
```

Every Matrix whose OID matches is checked separately, so a Draft with UNIQUE_1 and UNIQUE_2 has both checked. Matching ignores upper and lower case.

A Matrix OID setting also accepts a regular expression starting with `^`. End the expression with `$` and not with `*`, because a trailing `*` is always read as the wildcard above:

```
^(UNIQUE|PRINT).*$
```

A `*` on its own is not accepted. It would select every Matrix in the Draft, including the ones the Diagnostic is meant to compare against, so name the Matrix or use a wildcard which selects only the ones to check. For the same reason, the Diagnostics which compare one Matrix against the others need at least one Matrix left over once the Matrix OID and Matrix Exclusions settings have been applied.

If the expression cannot be read, the Diagnostic does not run and gives the expression and the problem with it as the reason.
