Flag conventions

This guide explains best practices for creating conventions around flag names, keys, and templates. It describes how LaunchDarkly can help you enforce your conventions. We recommend using a flag naming convention that gives your organization’s members an intuitive sense of the purpose and scope of a flag. Members should know what behavior the flag controls and how it will change just by looking at the flag name and its variations. Creating a comprehensive and well-documented naming convention requires some initial effort, but results in members being able to quickly and easily find flags, name flags, and understand their purposes. We also recommend using a flag key convention to match your organization’s coding standards. For example, LaunchDarkly can help you enforce specific casing for your flag keys.

​

Concepts

You should understand the following concepts before you read this guide:

​

Temporary and operational flags

Most feature flags fall into one of two main categories: temporary or operational. You can wrap a temporary flag around code for a new or improved feature, and use it to release the feature to customers all at once or in increments. After you verify the new code is stable and roll out the feature to 100% of customers, you should delete the temporary flag. To learn more about rollouts, read Percentage rollouts. Operational flags control or change how your app or service operates. Often, these changes happen in response to unplanned events, such as traffic spikes or third-party service failures. You can integrate operational flags with application performance management (APM) tools to automate flag shut off. Operational flags are usually permanent. To learn more about using operational flags with observability tools, read Monitoring tools.

​

Flag links

You can use flag links to view external mentions of flags from other tools and services. Links to external flag references allow you to collaborate more easily and quickly review relevant flag contexts. To learn more, read Flag links.

​

Tags

Tags are labels that help you categorize flags. You can use them to group related flags, such as marketing or devOps. To learn more, read Tags.

​

Why create a flag naming convention?

Naming conventions are an important part of your organization’s experience of using feature flags. A good naming convention should convey:

• The intended behavior and impact of the application when the flag serves a variation.
• The scope and target of the behavior.
• The purpose of a feature flag in both the Flags list and source code.

Poorly-named flags can result in the following consequences:

• Unclear or ambiguous flag impact and intent. For example, does a flag named “Dark mode” turn on dark mode, or allow end users to choose dark mode?
• Flags used for multiple purposes in an application by mistake.
• Difficulty remembering and adhering to the naming convention.
• Difficulty discovering and searching for flags from the Flags list.

Continue reading to learn how to avoid these pitfalls and create a useful, usable flag naming convention.

​

Get started

If your organization has a coding style guide, you may want to build your flag naming and flag key conventions off of your style guide, add your conventions to the guide, or store them together. If your organization doesn’t have a coding style guide, consider what information about a flag might be useful for future contributors to know. Your conventions should include instructions on:

• Which flag attributes make up the flag name and flag key
• How those components should be phrased and formatted
• How they should be ordered

If your organization uses AgentControl, extend your conventions to cover AgentControl configs as well. Configs also have names, keys, descriptions, and tags, and members search and filter them the same way. To learn more, read Config naming conventions.

​

Flag kinds

In your flag conventions, we recommend that you describe each kind of flag used by your organization and the specific naming convention for that kind. Possible flag kinds you may want specific naming conventions for include “release,” “configuration,” “allow,” “show,” and “database” flags. In the convention for each flag kind, you should include:

• The action or prefix used
• An example flag name, key, and the semantic meaning of the flag as a sentence
• Examples when you should and should not use this kind of flag

To learn more, read Flag kind examples.

​

Consider shared architecture

When using a shared project architecture, all of your work groups should be able to adopt the naming convention easily. If you use feature flagging on multiple platforms, consider whether you use single flags for multiple platforms or a different flag for each platform. This can impact your flag naming convention by requiring more or less precise flag names. You may want to assign prefixes to flags to designate them as belonging to members with particular roles. For example, you could add the “DBA” prefix to the name of flags managed by database administrators (DBAs). Then, in your custom role permissions for DBAs, you can grant permission to flags with keys that begin with dba. However, we generally recommend using views to manage flag access, rather than name prefixes. To learn more, read Views.

​

The components of a flag name

Flag names should read as an instructional sentence that begins with an action and concludes with a subject. The action describes purpose and behavior of the flag. This should be a single verb and an optional category, followed by a colon. Some example actions are “Release:” and “Release Mobile:”. The subject describes the target and scope of the flag. Some example subjects are “Widget” and “Homepage banner color.” You should be able to read the name as a sentence that describes the purpose and scope of a flag. For example:

• “Rollout: a new feature”
• “Configure: a setting”
• “Allow: an action”
• “Enable: an entitlement”
• “Show: an offer”

The exception to this is flags that are a proxy for the state of an external system or process. For these flags, you may not need an action in the flag name. For example:

• “DB: widget table exists”
• “Compliance: GDPR enforced”

Other useful facts you can include in a flag name are:

• The effect of changing its value
• Where that effect happens, such as the interface element or page affected
• Which work group is responsible for it
• Whether it is temporary or permanent
• The date it was created

By default, flag keys match flag names with minor adjustments for spaces or special characters. LaunchDarkly can enforce flag key conventions for you, which can help you standardize flags across your projects.

​

Flag key conventions

Flag keys are important. You use the flag key to reference the flag in your code. A suggested key auto-populates from the flag name you enter, but you can customize it if you wish. If you would like to standardize how members of your organization define feature flag keys, you can specify a convention in the project settings and LaunchDarkly will enforce your convention for all new flags. You can specify whether your flag keys should use camel case, Pascal case, snake case, or kebab case. You can also specify whether your flag keys require a specific prefix. To learn more, read Flag key conventions.

​

View naming conventions

If you use views to group flags, create a naming convention for them as well. A view has a name and a key that you specify when you create it. We recommend naming views after durable parts of your system, such as a component, service, or product area, rather than after a team or work group. Team names and responsibilities change, and a view’s key outlasts them. You can change which flags a view contains at any time as ownership shifts, so the view’s contents can follow your organization even when its name does not. To learn more, read Create views.

​

Config naming conventions

If your organization uses AgentControl, create a similar naming convention for your configs. A config has a name and a key that you specify when you create it. Name a config for the behavior it controls in your application, not for the model or provider it currently uses. Because Configs let you change models, prompts, and settings without redeploying, a name like “Support summarizer” stays accurate if you change models. Configs support descriptions and tags. Record the details that don’t belong in the name, such as which part of your product calls the config.

​

Flag templates

In addition to flag naming and key conventions, LaunchDarkly also lets you to set project-wide default settings for different types of flags. For example, if you want kill switch flags to be permanent and release flags to be temporary, you can set that default in your flag templates. You can set up flag templates for each type of flag that your organization commonly uses to help standardize features across your project. Unlike flag key conventions, LaunchDarkly does not enforce flag templates. For example, if your release flag template specifies that release flags are temporary and are always labeled with a “release” tag,anyone with editing permission can still update the tag for an individual flag. To learn more, read Flag templates.

​

Flag kind examples

This section includes examples of naming schemes and best practices for specific flag kinds, including temporary release flags and several types of long-lived operational flags. When naming a flag, use the most specific category that you can. This ensures that all flags within that category have similar semantics and variations. Expand the sections below for examples of each kind, when you should use them, and how you might name them.

​

Managing flag keys

We typically recommend using the automatically generated flag key, with only minor changes for style and consistency. For example, if you have a flag named “Release: optional dark mode (ODM) function” the generated key would be release-optional-dark-mode-odm-function. Consider changing the generated key to release-odm-function for brevity. If you customize a flag key, remember that you can only do this while creating the flag. After you create the flag, the flag key is set and cannot change. If you set a custom key, it should be applicable for the entire lifetime of the flag. For example, you shouldn’t include team names in the flag key, because team names and responsibilities may change over the lifetime of the flag.

​

Effective flag descriptions

In addition to naming best practices, you can also document flag description best practices. Flag descriptions should be no longer than one or two sentences. Don’t repeat any information already present in the flag’s name. Instead, focus on other things you want your teammates to know about the flag. This might include:

• What enabling targeting will do
• What side effects it may cause
• Who is responsible for this flag
• When you can remove the flag

You can format flag descriptions using Markdown and include in-line Confluence links.

​

Tags

Tags are useful for grouping flags and configs by particular details. For example, if you have a set of long-lived flags that you intend for operational use, you can tag them with operational. If you have flags that have special targeting for end users in Canada, you can tag them canada. To learn more, read Tags. Try to reuse existing tags as much as possible. This streamlines the Flags list and makes it easier to find things later.

​

Flag variation names

When you create flag variations, you should add variation names and descriptions. Variation descriptions should describe the behavior of the application when the variation is served and any related side effects or required conditions. This is particularly important for non-boolean flags.

​

Practices to avoid

Some organizations use the following practices in their flag naming conventions. In this section, we discuss why we don’t recommend these practices, and what to do instead.

​

Avoid including ticket or sprint numbers in the flag name

Including ticket or sprint numbers in flag names lets you quickly identify which flags are related to a ticket or sprint. However, we advise against this because flags are not always tied to a specific sprint, or may be tied to several tickets. Instead, we recommend using flag links to associate a flag with particular tickets. Some organizations include sprint numbers in flag names to avoid naming conflicts. However, if you need to include sprint numbers to differentiate between multiple flags using the same name, the flag names are likely not descriptive enough. Instead, tweak your flag naming conventions so they are sufficiently descriptive and unique. If you must include a ticket or sprint number in a flag’s metadata, we recommend including it in the description or as a tag instead.

​

Avoid including team or work group names in the flag name

You shouldn’t include team or work group names in a flag’s name or key, because team names and responsibilities may change over the lifetime of the flag. Instead, link flags to a view for the team or component that owns them, and scope your role policies to that view. Unlike a name or key, you can change which flags a view contains as ownership shifts. To learn more, read Onboarding to views. You can also designate a flag maintainer for a specific flag to help track its ownership and maintenance. To give a group a list of only the flags that are relevant to their work, use the View menu on the Flags list. Groups can also save shortcuts to filtered Flags lists. To learn more, read Limit to views and Save shortcuts to filtered Flags lists.

​

Avoid using machine-generated names

You may be generating flag names automatically from an external system that are not human-readable. We do not recommend this, because it’s important for all stakeholders, including those using the user interface (UI), to understand what a flag does. If a flag’s name and key do not convey the intent of the flag, mistakes are easier to make and the scope of the flag may grow. If you must use machine-generated flag names, you should include your flag metadata in flag descriptions and tags instead.

​

Conclusion

A set of clear and comprehensive flag conventions allows your organization to quickly and easily discover and understand the purpose of any given feature flag. It also relieves cognitive load on your engineers when creating and working with flags. Creating flag conventions for your organization is one of the many ways to set up your organization for success when using feature flags.