Commit 914170d2 authored by Daniel Cheng's avatar Daniel Cheng Committed by Commit Bot

[UMA] Clarify documentation for logging histogram enums.

Bug: 705169
Change-Id: I0f232f96e545de8fef2ed3386f08cc949ecf2512
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1595650
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: default avatarAlexei Svitkine <asvitkine@chromium.org>
Cr-Commit-Position: refs/heads/master@{#657652}
parent 5af6530b
...@@ -95,69 +95,92 @@ the same histogram. For example, if you want to count pages opened from the ...@@ -95,69 +95,92 @@ the same histogram. For example, if you want to count pages opened from the
history page, it might be a useful comparison to have the same histogram history page, it might be a useful comparison to have the same histogram
record the number of times the history page was opened. record the number of times the history page was opened.
If few buckets will be emitted to, consider using a [sparse If only a few buckets will be emitted to, consider using a [sparse
histogram](#When-To-Use-Sparse-Histograms). histogram](#When-To-Use-Sparse-Histograms).
You may append to your enum if the possible states/actions grows. However, you #### Requirements
should not reorder, renumber, or otherwise reuse existing values. Definitions
for enums recorded in histograms should be prefixed by the following warning: Enums logged in histograms must:
```c++
// These values are persisted to logs. Entries should not be renumbered and - be prefixed with the comment:
// numeric values should never be reused. ```c++
``` // These values are persisted to logs. Entries should not be renumbered and
// numeric values should never be reused.
```
- be numbered starting from `0`. Note this bullet point does *not* apply for
enums logged with sparse histograms.
- have enumerators with explicit values (`= 0`, `= 1`, `= 2`), to make it clear
that the actual values are important. This also makes it easy to match the
values between the C++/Java definition and [histograms.xml](./histograms.xml).
- not renumber or reuse enumerator values. When adding a new enumerator, append
the new enumerator to the end. When removing an unused enumerator, comment it
out, making it clear the value was previously used.
If your enum histogram has a catch-all / miscellaneous bucket, put that bucket
first (`= 0`). This will make the bucket easy to find on the dashboard if
additional buckets are added later.
#### Usage
The enums themselves should have explicit enumerator values set (`= 0`, `= 1`, Define an `enum class` with a `kMaxValue` enumerator:
`= 2`), to make it clear that the actual values are important and to make it
easy to match the values between the C++ definition and
[histograms.xml](./histograms.xml).
For new enums used in histograms, prefer using an enum class with a kMaxValue ```c++
element, like this:
```c++ {.good}
enum class NewTabPageAction { enum class NewTabPageAction {
kUseOmnibox = 0, kUseOmnibox = 0,
kClickTitle = 1, kClickTitle = 1,
kOpenBookmark = 2, // kUseSearchbox = 2, // no longer used, combined into omnibox
kOpenBookmark = 3,
kMaxValue = kOpenBookmark, kMaxValue = kOpenBookmark,
}; };
``` ```
`kMaxValue` is a special enumerator value that shares the value of the highest
enumerator: this should be done by assigning it the name of the enumerator with `kMaxValue` is a special enumerator that must share the highest enumerator
the highest explicit integral value. There is a presubmit check which will value, typically done by aliasing it with the enumerator with the highest
enforce this semantic. Enums defined this way have better type checking support value: clang automatically checks that `kMaxValue` is correctly set for `enum
from the compiler, allow inferring kMaxValue from the type, and allow `switch` class`.
statements over them will not need to handle an otherwise unused sentinel value.
The histogram helpers use the `kMaxValue` convention, and the enum may be
Enumerators defined in this way should be recorded using the two argument logged with:
version of `UMA_HISTOGRAM_ENUMERATION`:
``` ```c++
UMA_HISTOGRAM_ENUMERATION("NewTabPageAction", action); UMA_HISTOGRAM_ENUMERATION("NewTabPageAction", action);
``` ```
which automatically deduces the range of the enum from `kMaxValue`.
If you need to record a histogram based on an enum without kMaxValue, you can or:
use the three argument version, which takes the number of buckets as the argument, e.g:
```c++ ```c++
UMA_HISTOGRAM_ENUMERATION("NewTabPageAction", action, UmaHistogramEnumeration("NewTabPageAction", action);
NewTabPageAction_MaxValue + 1);
``` ```
This is often seen with enums defined with a sentinal enumerator value at the #### Legacy Enums
end, relying on the compiler to keep the value up to date:
**Note: this method of defining histogram enums is deprecated. Do not use this
for new enums.**
Many legacy enums define a `kCount` sentinel, reying on the compiler to
automatically update it when new entries are added:
```c++ ```c++
enum class NewTabPageAction { enum class NewTabPageAction {
kUseOmnibox = 0, kUseOmnibox = 0,
kClickTitle = 1, kClickTitle = 1,
kOpenBookmark = 2, // kUseSearchbox = 2, // no longer used, combined into omnibox
kOpenBookmark = 3,
kCount, kCount,
}; };
```
These enums must be recorded using the legacy helpers:
```c++
UMA_HISTOGRAM_ENUMERATION("NewTabPageAction", action, NewTabPageAction::kCount); UMA_HISTOGRAM_ENUMERATION("NewTabPageAction", action, NewTabPageAction::kCount);
``` ```
Finally, if your enum histogram has a catch-all / miscellaneous bucket, put that or:
bucket first (`= 0`). This will make the bucket easy to find on the dashboard
if later you add additional buckets to your histogram. ```c++
UmaHistogramEnumeration("NewTabPageAction", action, NewTabPageAction::kCount);
```
### Flag Histograms ### Flag Histograms
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment