Introduction

Enum naming in C# affects readability, API stability, and serialization behavior more than many teams expect. Consistent naming for enum types and their matching properties helps avoid ambiguous state modeling. Good conventions also reduce migration risk when enums cross service boundaries.

Name Enum Types by Semantics

For single-choice state enums, use singular PascalCase names.

1public enum OrderStatus
2{
3    Pending,
4    Paid,
5    Shipped,
6    Cancelled
7}

A singular type communicates that one value is active at a time. Plural naming here often causes confusion.

Name Enum Members Clearly

Member names should be concise and domain-oriented. Avoid repeating the enum type name inside each member.

Good style:

• 'OrderStatus.Pending'
• 'OrderStatus.Shipped'

Avoid noisy style such as OrderStatusPending because call sites already include type context.

Match Property Names to Domain Language

Properties that store enum values should use domain nouns, not implementation labels.

1public sealed class Order
2{
3    public OrderStatus Status { get; set; }
4}

If class has several status dimensions, use explicit property names such as PaymentStatus and ShipmentStatus.

Flags Enums Use Different Convention

For bitmask-style combinable values, use [Flags] and plural enum type names.

1using System;
2
3[Flags]
4public enum UserPermissions
5{
6    None = 0,
7    Read = 1,
8    Write = 2,
9    Delete = 4,
10    Admin = 8
11}
12
13public sealed class User
14{
15    public UserPermissions Permissions { get; set; }
16}

Plural naming is appropriate here because multiple values can coexist.

Stabilize Numeric Values for Contracts

If enums are persisted or sent over APIs, assign explicit numeric values.

1public enum PaymentStatus
2{
3    Pending = 0,
4    Approved = 1,
5    Rejected = 2
6}

Explicit numbering prevents accidental contract drift when members are reordered.

Serialization-Friendly Naming Strategy

When enums are serialized as strings, member names become part of external contract. Keep names stable and avoid unnecessary renames.

1using System.Text.Json.Serialization;
2
3public sealed class PaymentDto
4{
5    [JsonConverter(typeof(JsonStringEnumConverter))]
6    public PaymentStatus Status { get; set; }
7}

If rename is required, plan backward compatibility and client migration carefully.

Keep Display Labels Separate

Enum members should be code identifiers, not user-facing text. Map display labels outside enum definition.

1using System.Collections.Generic;
2
3public enum ShipmentState
4{
5    PendingPickup,
6    InTransit,
7    Delivered
8}
9
10var labels = new Dictionary<ShipmentState, string>
11{
12    [ShipmentState.PendingPickup] = "Pending pickup",
13    [ShipmentState.InTransit] = "In transit",
14    [ShipmentState.Delivered] = "Delivered"
15};

This separation simplifies localization and UI wording changes.

Team Convention Checklist

A useful review checklist:

1. Single-choice enums are singular and PascalCase.
2. Flags enums are plural with [Flags].
3. Properties use domain names, not suffix-heavy labels.
4. Persisted enums have explicit numeric values.
5. UI labels are not embedded in enum identifiers.

Consistent conventions reduce codebase entropy over time.

When introducing new enums, include one example usage in unit tests or API examples so naming intent is visible in real call sites, not only in static style rules.

Common Pitfalls

• Using plural enum names for single-state values.
• Adding redundant Enum or Value suffixes everywhere.
• Renaming serialized enum members without migration plan.
• Mixing display text concerns into enum identifiers.
• Omitting explicit numeric assignments for persisted contracts.

Summary

• Use singular enum names for single-choice states and plural for flags sets.
• Keep member names concise and domain-centered.
• Name matching properties by domain meaning.
• Stabilize numeric values when enums are part of persisted or public contracts.
• Separate UI labels from code identifiers for maintainable design.