What are feature flags used for in code standards?

• A. To hide developers' messages
• B. To increase compile time
• C. To enable/disable features safely, control releases, and perform gradual rollouts without deploying new code
• D. To restrict access to the repository

Answer: (C)

Feature flags are about turning features on or off at runtime to manage releases safely. They act as switches in your code or configuration that let you enable a feature for some users or environments without needing a new deployment. This lets you ship the code, test in production, roll out gradually (canary or staged rollouts), run experiments, and quickly disable a feature if something goes wrong. In short, they decouple deployment from release and reduce risk during introduction of new functionality.

Hiding developers' messages isn’t the goal of feature flags, and flags aren’t meant to increase compile time or restrict repository access. Those options describe separate ideas (communication aids, performance concerns, and access control) and don’t capture the intended use of feature flags.

As you use feature flags, keep in mind the importance of lifecycle management: use them with clear naming, plan for cleanup once a feature is fully rolled out, and apply appropriate scope (per-user, per-group, or per-environment) to avoid flag debt.