# Naming Conventions for Feature Flags

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

There are [two hard things](https://martinfowler.com/bliki/TwoHardThings.html) 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.

## Enforce Your Conventions

Even with the best naming conventions, typos happen. `Flipper.enabled?(:serach)` silently returns `false` when you meant `:search`, which can be a painful bug to track down.

The [strict adapter](/docs/adapters/strict) catches these mistakes by raising an error or warning whenever your code checks a feature that doesn't exist. Enable it in development and test to get immediate feedback:

```ruby
Rails.application.configure do
  config.flipper.strict = Rails.env.local? && :warn
end
```

With strict mode enabled, checking an unknown feature will warn you immediately instead of silently returning `false`.