Refactor experiments local var naming #1271
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Two parts, both rather superficial…
Simplify the implementation of
experiments.IsEnabled()
. Go'smap
type returns the zero-value of its value type for missing keys; somap[string]bool
returnsfalse
for missing keys.That means we don't need any extra logic to check for the existence of the key.
The rest of the PR is mostly var renaming to make the implementation of Enabled() clearer.
Idiomatic Go uses
ok
to indicate whether a key existed in a map, e.g.value, ok := experiments["foo"]
.Whereas we were using it to refer to the boolean value of the
map[string]bool
in the context of a range,i.e.
for key, ok := range experiments
.And
var enabled []string
as the accumulator list of enabled experiments is problematic becauseenabled
isn't exclusively plural; the sameenabled
name could also refer to a boolean value in the experimentsmap[string]bool
. So this patch renames the list tokeys
, and also useskey
instead ofexperiment
everywhere to refer to experiment keys.With the name
enabled
no longer being used for a list of enabled keys, this patch usesenabled
instead ofok
, resulting in a clearerif enabled { ... }
.