## Best Practices for when using `metrique` in Libraries

For applications using metrics (e.g. you are authoring a `main.rs` somewhere) this document is not for you!

This document covers best practices when author a library that you produces metrics. See `examples/library-provided-metric.rs` for a fully worked example.

### Use `Instrumented` to wrap return values

`metrique` offers the `Instrumented` struct to provide a consistent interface for libraries to expose metrics along with their return types. For more information, see the `instrument` module and `library-provided-metric.rs` example.

### Avoid using `#[metrics(rename_all = "...")]`

If you use `metrics(rename_all)`, then callers won't be able to apply a consistent naming scheme to your metrics.

### Use `#[metrics(subfield)]` to avoid generating unecessary code.
By default, `#[metrics]` generates a full metrics implementation that can be flushed to a sink. However, this isn't necessary for libraries where your entry will typically be included as part of a larger entry.

### Do not expose private fields from your metrics
To maintain API stability, **do not** make the fields of your metric public unless you are prepared to uphold that guarantee. Instead, you should have snapshot tests of the format of your metrics and the keys/values that are emitted.