TypeScript Enum Naming Conventions

As a TypeScript developer with over a decade of experience working with enterprise-scale applications, I thought I would share the best practices for naming TypeScript enums. These are the naming conventions I have implemented in my own work and established as standards across development teams in major tech companies. While working with Enums in TypeScript, you should follow these best practices.

Why Enum Naming Conventions Matter in TypeScript?

Here are a few reasons why naming conventions for Enums matter in TypeScript:

• Improve code readability
• Reduces cognitive load when onboarding new team members
• Prevents confusion and ambiguity
• Makes codebase searching more efficient
• Ensures consistency across projects and teams

As Jake, a senior developer at a Fortune 500 company I consulted for, once told me: “Well-named enums are like well-organized road signs—they tell you exactly where you are and where you’re going in the codebase.”

Basic TypeScript Enum Syntax Recap

For those newer to TypeScript, let’s quickly review what enums are. An enum (enumeration) is a way to define a set of named constants. They make it easier to document intent or create a set of distinct cases.

enum Direction {
  Up,
  Down,
  Left,
  Right
}

With this foundation, let’s explore the naming conventions.

Now, let me explain to you the naming conventions for Enums in TypeScript with clear examples.

Check out TypeScript Convert String to Enum

PascalCase for TypeScript Enum Names

The first and most fundamental convention is using PascalCase (UpperCamelCase) for enum names in TypeScript.

Here is an example.

✅ Do:

enum UserRole {
  Admin,
  Editor,
  Viewer
}

❌ Don’t:

enum userRole {
  Admin,
  Editor,
  Viewer
}

enum user_role {
  Admin,
  Editor,
  Viewer
}

Check out Iterate Over Enums in TypeScript

Singular vs. Plural Enum Names in TypeScript

I recommend using singular nouns for TypeScript enum names unless the enum represents a collection.

Here are the dos and don’ts with examples.

✅ Do:

enum Color {
  Red,
  Green,
  Blue
}

enum HttpMethod {
  Get,
  Post,
  Put,
  Delete
}

❌ Don’t:

enum Colors {
  Red,
  Green,
  Blue
}

The exception is when the enum represents a collection or group:

enum SocialMediaPlatforms {
  Facebook,
  Twitter,
  Instagram,
  LinkedIn
}

Read TypeScript Enum Reverse Mapping

TypeScript Enum Member Naming Conventions

Enum member naming can follow different patterns depending on your team’s preferences and the nature of the enum. I’ll cover the three most common approaches for TypeScript Enum member naming conventions.

1. PascalCase for Enum Members

This is the most common convention I’ve seen in enterprise TypeScript codebases:

enum UserRole {
  Admin,
  ContentEditor,
  SubscribedUser,
  Guest
}

2. SCREAMING_SNAKE_CASE for Enum Members

Some teams prefer this convention, especially those coming from Java or C# backgrounds:

enum HttpStatusCode {
  OK = 200,
  CREATED = 201,
  BAD_REQUEST = 400,
  UNAUTHORIZED = 401,
  NOT_FOUND = 404,
  INTERNAL_SERVER_ERROR = 500
}

3. Prefixing Enum Members with the Enum Name

In certain scenarios, especially when using string enums, prefixing the members with the enum name can avoid naming collisions. Here is an example.

enum LogLevel {
  LogLevelDebug = 'DEBUG',
  LogLevelInfo = 'INFO',
  LogLevelWarning = 'WARNING',
  LogLevelError = 'ERROR'
}

My Recommended Approach

After working with numerous teams across the USA, I’ve found that the most effective convention combines:

1. PascalCase for enum names
2. PascalCase for enum members
3. Prefixing only when necessary for clarity

enum CardType {
  Visa,
  Mastercard,
  Amex,
  Discover
}

enum ApiResponse {
  Success,
  ValidationError,
  ServerError,
  NetworkError
}

Check out TypeScript Enum vs Union Type

Special Considerations for String Enums in TypeScript

String enums, introduced in TypeScript 2.4, deserve special consideration. With string enums, each member must be initialized with a string literal or another string enum member.

Use kebab-case or snake_case for String Values

When using string enums, I recommend using kebab-case or snake_case for the string values while maintaining PascalCase for the enum members:

enum ApiPermission {
  ReadUsers = 'read-users',
  WriteUsers = 'write-users',
  DeleteUsers = 'delete-users',
  ManageSettings = 'manage-settings'
}

This approach makes the enum values more suitable for APIs, URL parameters, and database representations.

Namespace-like Prefixes for Related Enums

When working with related enums, using a common prefix can help organize them:

enum UserActionType {
  Create,
  Update,
  Delete
}

enum UserFilterType {
  ByName,
  ByEmail,
  ByRole
}

enum UserSortType {
  NameAscending,
  NameDescending,
  DateJoined
}

Add Enum Suffixes for Clarity

In large codebases, I’ve found that adding an “Enum” suffix can improve clarity, especially when enums are exported:

export enum PaymentMethodEnum {
  CreditCard,
  PayPal,
  BankTransfer,
  ApplePay,
  GooglePay
}

This makes it immediately clear that you’re dealing with an enum when importing it in another file.

Comparative Analysis of TypeScript Enum Naming Approaches

Here’s a table comparing different naming conventions with their pros and cons:

Convention	Example	Pros	Cons
PascalCase enum with PascalCase members	enum Color { Red, Green, Blue }	Follows standard TypeScript convention, consistent with class naming	Members may conflict with other identifiers
PascalCase enum with SCREAMING_SNAKE_CASE members	enum Color { RED, GREEN, BLUE }	Members stand out clearly as enum constants	Inconsistent with typical TypeScript style
Prefixed members	enum Color { ColorRed, ColorGreen, ColorBlue }	Prevents naming collisions	More verbose, redundant
“Enum” suffix	enum ColorEnum { Red, Green, Blue }	Clear identification as enum when imported	Slightly more verbose

Check out Get Key by Value from enum String in Typescript

Naming Conventions for Complex Enum Use Cases

Now, let me show you some naming conventions for complex enum use cases.

Bit Flag Enums

When creating bit flag enums (enums that can be combined using bitwise operators), use power-of-two values and consider using a plural enum name:

enum Permissions {
  None = 0,
  Read = 1 << 0, // 1
  Write = 1 << 1, // 2
  Delete = 1 << 2, // 4
  Manage = 1 << 3, // 8
  All = Read | Write | Delete | Manage // 15
}

// Usage
const userPermissions = Permissions.Read | Permissions.Write;

if (userPermissions & Permissions.Write) {
  console.log('User has write permission');
}

Enums with Associated Metadata

For complex scenarios where enum members need associated metadata, consider using an object map alongside the enum:

enum StateCode {
  CA,
  NY,
  TX,
  FL
}

const StateMetadata: Record<StateCode, { name: string; capital: string }> = {
  [StateCode.CA]: { name: 'California', capital: 'Sacramento' },
  [StateCode.NY]: { name: 'New York', capital: 'Albany' },
  [StateCode.TX]: { name: 'Texas', capital: 'Austin' },
  [StateCode.FL]: { name: 'Florida', capital: 'Tallahassee' }
};

// Usage
console.log(StateMetadata[StateCode.CA].capital); // Sacramento

Read Get Distinct Values from an Array in TypeScript

Best Practices for Documenting Enums in TypeScript

Proper documentation enhances the value of well-named enums. I always follow these documentation practices:

Add JSDoc Comments to Enums

/**
 * Represents the possible authentication methods for the application.
 */
enum AuthMethod {
  /**
   * Standard username and password authentication
   */
  Password,

  /**
   * Single Sign-On using OAuth providers
   */
  OAuth,

  /**
   * Multi-factor authentication
   */
  MFA,

  /**
   * Biometric authentication (fingerprint, face recognition)
   */
  Biometric
}

Evolving Enums Over Time

You’ll likely need to add new enum members as your application grows. Follow these guidelines:

• Add new members at the end of the enum to prevent shifting existing numeric values
• For string enums, the order doesn’t matter as much
• Consider using const enums for performance optimization when values won’t change
• Document deprecated enum members but don’t remove them immediately to avoid breaking changes

enum PaymentProvider {
  Stripe, // Original
  PayPal, // Original
  // Square, // Removed/commented instead of deleting

  /**
   * @deprecated Use Braintree instead
   */
  AuthorizeNet, // Marked as deprecated

  Braintree, // New member added at the end
  ApplePay   // Another new member
}

Check out TypeScript Promise

Enum Naming in Different Project Types

The context of your project might influence your enum naming conventions:

Library/SDK Projects

When developing libraries or SDKs that others will consume, be extra careful with enum naming to avoid conflicts:

export enum YourLibNameHttpMethod {
  Get,
  Post,
  Put,
  Delete
}

Internal Enterprise Applications

For enterprise applications used within a company, consistency is key:

enum DepartmentType {
  Engineering,
  Marketing,
  Sales,
  HumanResources,
  Finance
}

ESLint Rules for Enforcing Enum Conventions

To enforce these conventions in your team, I recommend configuring ESLint rules. Add the following to your .eslintrc.js:

module.exports = {
  // ...other config
  rules: {
    '@typescript-eslint/naming-convention': [
      'error',
      {
        selector: 'enum',
        format: ['PascalCase']
      },
      {
        selector: 'enumMember',
        format: ['PascalCase']
      }
    ]
  }
};

Conclusion

In this tutorial, I have explained TypeScript Enum Naming Conventions and the best practices. PascalCase for enum names, thoughtful member naming, and proper documentation will make your TypeScript code more readable, maintainable, and professional. Do let me know if this helps.

You may also like:

• Check if a String Contains a Substring in TypeScript
• Capitalize the First Letter in TypeScript
• Format Date in Typescript