# Best practices

Due of the dynamic nature of Ruby, Rails, and Avo, you might be tempted to do a few things differently than how we envisioned them to be done.
It's ok if you want to keep doing them like that, but they might not be the most the optimum way of running Avo.

Here's a collection of best practices that we'd like you to know about.

## Avoiding `n+1` using `self.includes`

`n+1` issues happen, but they are pretty simple to mitigate using Avo.

Each resource has the `self.includes` option that helps you eager-load associations.

:::info Detailed documentation
`self.includes`
:::

## Avoid using `if/else` statements in `def fields`

You might be tempted to using `if/else` statements inside the `def fields` method.
This practice is discouraged and we'll try to explain why here.

Because of checks Avo makes during the request lifecycle, we need to know exactly which fields you have defined for your resource, no matter if they should be hidden or not to a user or in a certain scenario.

The alternative is to use the `visible` field option which will add the field on the list, but keep it hidden from the user based on the computed value.

### Example:

```ruby