Naming Conventions in C#

Consistent names make code easier to read, search, and maintain. C# conventions are designed to make the role of a symbol visible at a glance, even before reading its implementation.

PascalCase and camelCase

The two most common styles in C# are:

• PascalCase: Every word starts with an uppercase letter, such as CustomerAccount.
• camelCase: The first word starts with a lowercase letter, while later words start with uppercase letters, such as customerAccount.

PascalCase is generally used for types and public members. camelCase is generally used for parameters and local variables:

public class CustomerAccount
{
    public string AccountNumber { get; }

    public CustomerAccount(string accountNumber)
    {
        AccountNumber = accountNumber;
    }

    public void CloseAccount()
    {
        var closingMessage = $"Closing {AccountNumber}";
        Console.WriteLine(closingMessage);
    }
}

Why use PascalCase?

PascalCase makes word boundaries clear without spaces or underscores, which are not allowed in ordinary C# identifiers. It also creates a visual distinction between types and values:

CustomerAccount account = new CustomerAccount("A-100");

Here, CustomerAccount looks like a type, while account looks like an object or variable. This distinction helps readers understand code quickly and matches the conventions used throughout the .NET libraries.

Naming solutions and projects

Solutions and projects should usually use PascalCase and a meaningful product or organization name:

Contoso.Inventory.sln
Contoso.Inventory.Api.csproj
Contoso.Inventory.Application.csproj
Contoso.Inventory.Domain.csproj
Contoso.Inventory.Infrastructure.csproj
Contoso.Inventory.Tests.csproj

A solution name describes the overall product or system. Project names describe the responsibility of each project, often with a suffix such as Api, Application, Domain, Infrastructure, or Tests.

Avoid vague names such as Common, Helpers, or Misc when a more specific responsibility can be named. Broad names tend to become containers for unrelated code.

Namespaces and folders

Namespaces generally follow the project name and use PascalCase:

namespace Contoso.Inventory.Application.Orders;

Folders often mirror namespaces, although the compiler does not require them to match. Keeping them aligned makes files easier to locate:

Contoso.Inventory.Application/
└── Orders/
    ├── CreateOrderCommand.cs
    └── OrderService.cs

Common naming rules

Use these patterns as a practical baseline:

Private fields commonly use a leading underscore. This makes fields easy to distinguish from parameters and local variables, especially when names are similar:

public class OrderService
{
    private readonly IOrderRepository _orderRepository;

    public OrderService(IOrderRepository orderRepository)
    {
        _orderRepository = orderRepository;
    }
}

Acronyms and abbreviations

Treat acronyms like ordinary words in PascalCase and camelCase. Prefer HttpClient, JsonParser, and customerId over HTTPClient, JSONParser, and customerID:

public class HttpClientFactory
{
    public JsonParser CreateJsonParser() => new();
}

The exception is a short, established name that is part of an external API or domain vocabulary. Clarity and consistency matter more than applying the rule mechanically.

Name things after their purpose

Good names explain what a symbol represents or does:

var overdueInvoices = invoiceService.FindOverdueInvoices();

Names such as data, thing, and helper hide intent. A longer, precise name is usually better than a short name that forces readers to inspect surrounding code.

Final advice

Follow the conventions already used by the codebase, and use analyzers or editor configuration to enforce them consistently. Naming conventions work best when they are predictable: readers should be able to infer a symbol’s purpose and visibility from its name before investigating its implementation.

Check Microsoft Learn to read more about identifier naming rules and conventions.