Feature Flag Naming Conventions: The Guide to Names You Won't Regret

You named the flag newCheckout. Six months later, the checkout has been live for four months, three engineers have left, and nobody can remember whether the flag controls the new design, the new payment flow, or something else entirely. The flag is still in production. Nobody wants to delete it.

Feature flag naming is one of those decisions that feels trivial in the moment and expensive later. A good convention takes 10 minutes to agree on and saves hours of confusion over the lifetime of a codebase. This guide covers the conventions that work — with real examples and a checklist you can put into practice immediately.

Why Does Feature Flag Naming Matter?

Feature flags accumulate faster than teams expect. A team shipping weekly can add 2–4 flags per month; at 12 months that's 24–48 flags in production. Without a convention, each engineer invents their own schema. You end up with featureNewDashboard, enable_payments_v3, PAYMENTS_REFACTOR_2024, and tmp_killswitchall in the same codebase — none of which communicate when they were created, what they control, or when it's safe to delete them.

A naming convention solves three problems at once:

• Discoverability — engineers can scan a list of flags and understand the system without reading code.
• Lifecycle management — names that encode purpose and state make cleanup decisions obvious.
• Tooling integration — consistent prefixes let you filter, alert on, and audit flags programmatically.

Martin Fowler's Feature Toggles remains the canonical reference on flag lifecycle management, and naming is central to every pattern he describes. The cost of a bad name compounds over every line of code that reads it.

What Makes a Good Feature Flag Name?

Good feature flag names share three properties: they are descriptive, consistent, and lifecycle-aware.

1. Use a Prefix to Encode Type

Different flags serve different purposes. Encoding that purpose in the prefix makes it immediately clear how a flag should be treated:

A flag named exp_tells everyone on the team: this is temporary, it has a hypothesis, and it should be cleaned up when the experiment concludes. That single signal prevents a whole category of “is this safe to delete?” conversations.

2. Use snake_case and Stay Lowercase

Avoid camelCase (newCheckout), PascalCase (NewCheckout), and screaming snake (NEW_CHECKOUT). Stick with lowercase_snake_case — it reads cleanly in code, URL params, log output, and API responses, and it matches how most feature flag SDKs serialize flag keys internally.

3. Describe the Behavior, Not the State

Names like checkout_enabled or show_new_dashboard embed the current expected value into the name. This creates confusion when the flag is flipped: is checkout_enabled = false the normal state or an emergency kill switch?

Name flags by what they control, not by their expected value:

// ✅ Correct — describes the behavior
rel_checkout_v2
exp_homepage_hero_variant
ops_maintenance_mode

// ❌ Avoid — embeds the expected value
new_checkout_enabled
use_new_hero
disable_app

4. Include the Product Area

Vague names like feature1 or test_flag tell you nothing. A good name answers: what system or product area does this affect? The pattern to follow:

{prefix}_{product_area}_{description}

exp_billing_annual_toggle
rel_onboarding_v2_flow
ops_search_fallback
perm_beta_analytics

Naming Patterns That Scale

Three patterns cover most teams' needs:

Pattern A — Type · Area · Behavior (recommended for most teams)

exp_checkout_cta_test
rel_dashboard_v3
perm_beta_analytics
ops_email_queue_pause

Pattern B — Area-first (useful when filtering by product area)

checkout_exp_cta_test
dashboard_rel_v3
analytics_perm_beta

Pattern C — Date-scoped (useful for time-boxed experiments)

exp_2026q2_checkout_cta

Pattern C makes quarterly cleanup obvious — anything prefixed exp_2025 in 2026 is a candidate for removal. The tradeoff is longer names. Most teams do well with Pattern A. The most important thing is picking one and enforcing it consistently across the codebase and across teams.

What Are the Most Common Feature Flag Naming Mistakes?

1. Naming after the ticket

JIRA-2341 tells you where the work came from, not what it does. Tickets get closed and archived; flags live in production for months.

2. Encoding the expected value

is_feature_enabledbecomes misleading the moment you need to flip it off. Name what the flag controls, not whether it's on.

3. Abbreviations without a glossary

pmt_v3_rlout_exp might make sense today. In six months, nobody will know if pmtmeans “payment” or “permit”. If you abbreviate, document it.

4. Shared flags for multiple behaviors

A single flag that controls two independent code paths is a production incident waiting to happen. One flag, one responsibility — always.

5. No prefix or type signal

Without a prefix, all flags look the same in dashboards and alert channels. Add the type signal from day one — retrofitting it across 40 flags is painful and error-prone.

Feature Flag Naming Checklist

Before creating a flag, run through these 6 checks:

If any check fails, rename before creating. It's free now; it costs real engineering time later. For a deeper look at how feature flags fit into your overall deployment strategy, see our guide on feature flags.

Frequently Asked Questions

How long should a feature flag name be?

Aim for 3–5 components: prefix + product area + short description (e.g., exp_billing_annual_cta). Names under 40 characters fit cleanly in dashboards, code, and log output. If you need more, the flag may be controlling too many things.

Should feature flag names match variable names in code?

Yes, wherever possible. If your flag key is rel_checkout_v2, name the corresponding constant REL_CHECKOUT_V2 or Flags.RelCheckoutV2. Consistency between the flag key and the code constant prevents a subtle class of bug where a casing mismatch causes the SDK to silently return the default value.

How often should we audit flag names?

Quarterly is a sensible minimum. Set a recurring review to identify flags older than 90 days with no active rollout — these are candidates for removal. A good feature flag platform surfaces flag age and last-evaluated timestamps in the dashboard, which makes this review significantly faster than a manual grep.

What about flags migrated from another tool?

Migration is the right moment to clean up naming debt. Establish your convention first and migrate flags to the new names rather than importing the old ones. It requires a short dual-write period, but you'll avoid carrying bad names into a clean system.

Conclusion

Feature flag naming is a small decision with a long tail. The {type}_{area}_{behavior} pattern, enforced with lowercase_snake_case, is the practical starting point for most teams. Pair it with the 6-item checklist above and a quarterly cleanup ritual and your flag inventory stays healthy as the codebase scales.

Good naming makes flag decisions visible, lifecycle management obvious, and code reviews faster. It's one of the highest-leverage 10 minutes a team can spend before shipping their third flag. If you're evaluating which feature flag platform to adopt, compare the leading tools to find the right fit for your team's scale and workflow.