The Ultimate Guide to .NET Core

Naming Conventions in C#: A Comprehensive Guide

Integrally associated with writing clean, readable, and maintainable code in any programming language is the naming convention for C# itself. They standardize ways of giving names to variables, methods, classes, as well as to any identifiers in an interactive environment. By enforcing consistent naming, we remove part of the cognitive load necessary to understand the code and increase the odds of doing so free of errors.

In the language of C#, the .NET framework set up formal rules that developers must follow. These conventions are of course about consistency within a single project but also across the whole C# universe. Using these standards developers can be sure that their code adheres to industry best practices, helping to smooth code reviews and integration with other .NET libraries and applications.

Camel Casing

The first letter of the first word is lowercase and subsequent concatenated words are capitalized in camel casing. The name comes from a camel’s back, where it gives a ‘hump’ look and produces the style. Usually in C# we use camel casing to name private or internal fields and local variables inside a method.

For example, a variable that represents the customer’s last name would be called customerLastName. “Customer” starts with a lowercase ‘c’, “Last” and “Name” begin with upper case letters here. This convention makes identifying words in an identifier easier to read as the words are separated, without the use of underscores or spaces.

Camel casing is good because, in particular use cases, instance variable names tend to contain multiple words. This helps to prevent confusion between to variables that share similarity in names and quickly helps developers understand what a variable is intended for. Camel casing local variables and private fields allows for keeping the code structure clean and tidy by doing so over a period of time.

Pascal Casing

Pascal casing, also known as upper camel casing, is similar to camel casing but with one key difference: First, letters of every word, even the first word, are capitalized. So when naming public members of a class like classes, methods, properties, and events in C# we would commonly use Pascal casing. This convention follows .NET Framework Design Guidelines and has become the role model for the C# community.

For example, if one were to be representing a customer order, one might have a class named CustomerOrder and ProcessOrder() as her method to process the orders. The identifier starts with uppercase looks like ‘Customer’, ‘Order’ which is important part of code and starts with uppercase. Pascal casing makes it easier to read where, for example, the difference between a function and a variable is clear.

However this also greatly helps other developers that code against a public member of a class or library to quickly recognize and understand the public API of that class or library, by always using Pascal casing. This tells us that these members are indeed available from outside the class or assembly, as this is important for the continued good encapsulation and modularity that object oriented programming is all about.

Examples

public class Employee
{
    private int employeeId;
    private string firstName;
    private string lastName;

    public int EmployeeId
    {
        get { return employeeId; }
        set { employeeId = value; }
    }

    public string GetFullName()
    {
        return $"{firstName} {lastName}";
    }
}

Here employeeId, firstName, and lastName are private fields whose name are camel cased. Properties EmployeeId and GetFullName() use Pascal casing, so they are available publically. Giving a name to our outputs further clarifies source code structure.

Another example involves local variables within a method:

public void CalculateSalary()
{
    decimal baseSalary = 50000m;
    decimal bonusAmount = 5000m;
    decimal totalSalary = baseSalary + bonusAmount;
    Console.WriteLine($"Total Salary: {totalSalary}");
}

Under this structure, baseSalary, bonusCountry and totalSalary are local variables that are нamed using camel casing. It also encourages you not to use Pascal casing for methods and classes, apart from these two, making easy to differentiate them.

Tips and Guides

Be Consistent: Re-applying naming conventions over and over is not useful. To the contrary, maintainability and greatly reduced confusion are achieved when you follow patterns you already have created for your codebase, not re-inventing the wheel, otherwise.

Use Meaningful Names: Make a habit of the choosing a descriptive name for method, class an variable that clearly explains what it does. Do not use ambiguous or single letter identifiers, aside from loop counters.

Avoid Abbreviations: Don’t use abbreviations unless they are common (like HTML or XML) and will be understood by other developers. The code is also kept understandable to a wider audience by preventing the misconceptions that can often arise from the deconstruction of semantic functions and algorithms.

Capitalize Acronyms Correctly: In Pascal casing (for acronyms longer than 2 letters), capitalize only the first letter (e.g. XmlDocument, not XMLDocument). Also, capitalize both letters for two letter acronyms (e.g. IOStream).

Prefixes and Suffixes: Also, avoid using prefix like Get or suffix like Data when it’s not necessary. If you are comfortable with the GetEmployee() context, you might just use GetEmployeeData() instead.

Avoid Hungarian Notation: You don’t need to specify the type of variable you have (e.g. strName when it’s a string). Since modern IDEs and editor support the type information, this practise is obsolete.

Namespaces and Classes: Namespaces and classes are to be used in Pascal Casing. Namespaces should organize hierarchically (the company name and product name, e.g., Contoso.Financial.Reporting).

Event Handlers: When you have event handlers you use the On prefix and then the name of the event, thus OnButtonClick() .

If you follow these tips and stick to the standard naming conventions you add to the clean, efficient way that other people can work to understand it. This practice lets you grow your own development experience, and at the same time provides better collaboration with the people around you on your team and with the whole rest of the developer community.

dotnetcoreinfo

,