## Why is this an issue?

An assertion is a piece of code that’s used during development when the compilation debug mode is activated. It allows a program to check itself as it runs. When an assertion is `true`, that means everything is operating as expected.

In non-debug mode, all `Debug.Assert` calls are automatically left out (via the `Conditional("DEBUG")` mechanism). So, by contract, the boolean expressions that are evaluated by those assertions must not contain any side effects. Otherwise, when leaving the debug mode, the functional behavior of the application is not the same anymore.

The rule will raise if the method name starts with any of the following `remove`, `delete`, `add`, `pop`, `update`, `retain`, `insert`, `push`, `append`, `clear`, `dequeue`, `enqueue`, `dispose`, `put`, or `set`, although `SetEquals` will be ignored.

## How to fix it

In the following example, the assertion checks the return value of the remove method in the argument. Because the whole line is skipped in non-debug builds, the call to `Remove` never happens in such builds.

### Code examples

#### Noncompliant code example

    Debug.Assert(list.Remove("dog"));

#### Compliant solution

The `Remove` call must be extracted and the return value needs to be asserted instead.

    bool result = list.Remove("dog");
    Debug.Assert(result);

## Resources

### Documentation

- Microsoft Learn `Debug.Assert` Method
- Microsoft Learn Debugging, tracing, and profiling
- Microsoft Learn How to: Compile Conditionally with Trace and Debug
- Microsoft Learn Miscellaneous attributes interpreted by the C# compiler - `Conditional` attribute

### Articles & blog posts

- Wikipedia Side effect (computer science)