Documentation

Naming Conventions for Feature Flags

Learn how to structure and name your feature flags for maximum clarity and consistency.

There are two hard things in programming — cache invalidation and naming things. Feature flag names are no exception. A couple hard and fast rules:

• The name of a feature flag should be descriptive enough to understand what the flag is for, but not so long that it becomes hard to read or type.
• The name should be consistent with the conventions used in the rest of your organization/codebase.

Pick a Style

Pick a naming style and stick with it. The most important thing is consistency. Here are some examples of styles you can use:

1. We recommend snake case (trial_lifecycle_emails)
2. kebab case (trial-lifecycle-emails)
3. camel case (trialLifecycleEmails)
4. pascal case (TrialLifecycleEmails)

We'd also recommend staying away from spaces, punctuation, and special characters because you will be referring to these names in code (e.g. if Flipper.enabled?("Awkward Feature Name")) Plus, standardized and consistent formatting reduces the chances of typing the right key using the wrong formatting.

Keep It Short

Feature flag names should be short and descriptive. If you find yourself writing a long name, consider whether you can shorten it without losing clarity.

google_analytics is better than google_analytics_integration or google_analytics_tracking because it's clear that the flag is related to Google Analytics, and the shorter name is easier to type. It's also easier to remember becuause you don't have to double-check if you used "analytics" or "tracking" when you need to reference the flag in your code.

Use Prefixes

Succinct and relevant prefixes can help avoid naming collisions and make names more descriptive.

For example, we have a couple flags related to the events API in Flipper Cloud — event_receiving and event_enqueue. Using event_ as the prefix makes it clear that they are related to the same functionality. Naming those flags receiving and enqueue alone would be confusing (which receiving or enqueueing part of the app does this control?). In these cases, adding a succinct reference to the relevant area or module (logger, jobs, email, webhooks, etc.) can help clarify purpose.

That said, we don't recommend going wild with prefixes (or suffixes). Other feature flag systems often recommend prefixing the name with the:

• type (e.g. release, experiment, ops, etc.)
• longevity (temporary or permanent)
• team (e.g. engineering, marketing, security, etc.)

We don't recommend this, as it just makes flag names unnecessarily long and harder to type.

Instead, we recommend using the feature description and tags for organizational purposes. For example, you can tag all features related to marketing with marketing and then filter by that tag in the UI. You can also use the description field to add more context to the flag.