The 9 Coding Standards C# Developers Need to Get Started

C# is about objects, classes, and class methods. The runtime handles memory management so you don’t have to. Your C# code is compiled into an intermediate language and runs on the .NET platform. It’s a language built around productivity; therefore, the compiler does many optimizations so you can write clean, readable code.

There are some general standards that fluent C# writers follow. So, if you’re a developer who’s coming to C# from another programming language, you’ll want to know this stuff too! This post is an introduction to the most important standards and sets you on the course to other resources that can help build your C# prowess.

1. Casing

Naming is hard. And because it’s hard, we don’t want to confound the issue with mixed casing. Every language has its own casing standards. To add to the confusion, many organizations, or even teams, have their own standards. When there’s no standard in place, you might even see a cornucopia of every naming convention in just one page of code?I sure have!

There are three casings generally accepted by C# standards:

1. PascalCase: This is for class names, file names, namespace names, ALL method names, and public member names.
2. camelCase: This is used for member names that are not publicly accessible.
3. UPPER_CASE: You might also think of this as upper snake case. This is only used for constants.

There are some exceptions that exist in the world, and for good reasons.

Names like “Pascal_snake_case” or “snake_case” are sometimes used in unit testing. A descriptive method name such as Should_return_2_when_adding_1_and_1 is much easier to read. That’s the reason for snake casing in unit tests.

Event handlers (a type of method) often include an underscore to separate the target from the action. A classic example is Page_Load in ASP.NET. But this is not Pascal_snake_case. For example, in InputControl_Init, the InputControl is the target and Init is the event.

A hotly debated convention is the private member variable. Since this always refers to the class scope, it’s fine to use camelCase for member variables. When you do, you really should use this.<memberName> to access it like?in the following example:

public class Person
{
    private string firstName;

    public void SayHello()
    {
        Console.WriteLine($"Hello, {this.firstName}!");
    }
}

In this example, the Person class has a private member variable firstName, which is only accessible from inside this class. The SayHello method is available to any consumer of this class. It accesses the firstName?variable through this?which refers to the current instance of Person.

Another common approach is to prepend the member name with an underscore. Here is the same example using that convention:

public class Person
{
    private string _firstName;

    public void SayHello(string firstName = null) 
    { 
        Console.WriteLine($"Hello, {firstName ?? _firstName}!");
    }
}

Using the underscore allows us to omit this when we use the variable. In the example, the method parameter has the same base name as a class member. Therefore, if we use underscore in all member variables, we can avoid accidentally taking the wrong variable.

Note to readers: ?? is a null coalescing operator?a nice shortcut, which means “if null, then.” Also, I used string interpolation in this example since it’s nicer to read than the old string.Format method.

Cardinal Casing Sins of C#

The following casing conventions from other languages will land you in C# hell…

Hungarian Notation

Prepending a type identifier to the name is a no-no!

Hungarian notation invites two problems in C#. For one, the name is misleading when the type changes. Another problem is readability. C# often uses custom types and interfaces. Names such as iDictNames and mpLateFeeMessageProcessor litter the code with extra unintelligibility (what is an “mp” anyway?).

New developers will have to learn the inside naming conventions, which slows down development and introduces operational risk. The IDE gives you plenty of information about the type if and when you need it.

Mixed Conventions

Mixed naming conventions make the program less readable. Be consistent and pay attention to readability. Sure, we’re programming a computer, but the code is really for humans. Computers would be perfectly fine with an entire program of 0s and 1s.

Keep your reader in mind when writing software and use the same casing rules throughout!

To illustrate further, here’s a small program that mixes many conventions:

class aPOORRLY_written-CLASS {
 public static int METHOD_FindHello_Get()
 {
                String LINE = null;
      for(iCURRENT_ITERATION =0; iCURRENT_ITERATION < _nMaxIterationCount; iCURRENT_ITERATION++)
{
if(c_MyReadingSomething_CLASS.READALINE(out LINE)){
                                                  if(LINE.Contains("Hello")){
response = 1;
}
return response;
}
}
  }

private const long _nMaxIterationCount = 100;
public static int iCURRENT_ITERATION = 0;
public static int response;
}

Sorry, that was probably fairly painful even for such a small program. Here’s a clean version:

internal class Hello
{ 
    public static bool ContainsHello()
    { 
        for(var i = 0; i < 100; i++)
        { 
            if(LineReader.ReadLine(out string currentLine)
               && currentLine.Contains("Hello"))
            { 
                return true;
            }
        }
        return false;
    }
} 

Although this code isn’t that great, it’s much cleaner than the previous example with mixed casing and many other inconsistencies. This next section will help you understand some of the other issues.

2. Formatting

We have formatting conventions for C#, just as we do in any programming language. Formatting has to do with line breaks, indentation, and spacing. True, the IDE will often help with formatting, but it doesn’t do everything for you.

Indentation

Indentation is a hotly contested issue in many languages. Should you use tabs or spaces? This post will not settle the argument. But it will establish that four is the proper number of spaces. Also, if you’re using tabs instead, the tab should be equal to four spaces. These are defaults in Visual Studio, and most IDEs have this preset for C#.

Brackets

In C#, brackets contain the scope of a namespace, class, interface, method, and the like. Brackets are major structural constructs and should always go on their own line. This SO post tries to rationalize it, but honestly, it’s just the common convention.

Terminator

A semicolon terminates a statement. It goes on the same line as the end of the statement, much like a period would. Don’t use extra semicolons?one is enough.

Extra Lines

One extra line is sufficient for separating methods or different sections of a class such as the list of member variables, constructors, and methods.

3. “var” Is Your Friend

Using?var is actually a good idea for all those short-lived variables. It not only saves a lot of redundancy, but it allows for more flexibility in the code. Basically, if you can already see the type based on the variable name, you’re good to go with var! Here are a few examples of var in practice:

var person = new Person(id);

var result = await _someApiClient.GetAsync(id, cancellationToken);

for(var i = 0; i < max; i++)
{
    // i is implicitly typed
}

var person = this.personFactory.GetOrCreate(id);
this.someDependency.SubmitPerson(person);

4. Always Use Access Modifiers

Always use access modifiers! I know, I know … the default is sometimes what you want: “private” for members, “internal” for classes. But it really does help to be explicit about this. It shows that you were purposeful in your intent.

And while you’re at it, use the lowest necessary modifier. This is equivalent to the principle of least privilege. For example, don’t use protected when private will do. Use protected internal to give access only to subclasses in the assembly. If your class is public and you want to share a member with a subclass outside the assembly, make the member protected. Here’s an example to clarify.

In my assembly, I make a class to read a certain file type.

public FileReader
{
    protected virtual string Read(string location)
    {
        // read file and return result
    }
}

You reference my assembly or use NuGet to add it to your project. Since the Read method is protected and virtual, you can not only access it from your own subclass, but you can override it.

5. Use Auto Properties

An auto property creates a backing field for you; you just can’t see it or access it. If you don’t need control over the backing field, don’t create one. Instead, just use the auto property (the shortcut is “prop”). It’ll save a lot of extra code!

public int Count { get; set; }

This is an example of an auto property. It makes your code much cleaner.

6. Where to Declare Variables

Declare variables as close as possible to their use. Some languages work better when you declare all your variables at the start of the function, but the C# compiler doesn’t care. It’ll do the optimal thing no matter where you put the variable. Put the variable close to its use so you have an easier time refactoring your code. In fact, your IDE allows you to highlight the section and right-click (or use Ctrl+.) to do some handy refactoring. If your variable is declared way up top, the refactoring will be overly complex or even downright impossible.

7. Code File Organization

You should only put one class, interface, struct, or enum in a single file. This makes the codebase easier to navigate. For this same reason, you should keep your code organized in folders within the projects.

A project is a collection of files that are related. The namespace should match the project name and the directory path it’s located in. For example, let’s say you have a project called Peoples and a Utilities directory (for, you know, utilities). A utility class to format names would look like this:

namespace Peoples.Utilities
{
    public class NameFormatter
    {
        public static string FormatName(Person person)
        {
            return $"{person.FamilyName}, {person.GivenName}";
        }
    }
}

This utility class would live within the Utilities folder of the Peoples project. Note the use of string interpolation rather than string.Format.

8. Use the Aliases, Jack!

All of the primitive types have aliases. String has string. Int32 has int. Int64 has?long. There are plenty more where those came from, and it’s the preferred way to refer to those types. Use them even if you’re calling a method on the type such as int.Parse.

9. “using” Is Your Friend!

When you have a disposable type, there’s a great little construct built into the language: using. It calls Dispose when the program flow leaves the scope. Here’s an example:

using(var connection = _connectionFactory.Get())
using(var stream = connection.OpenStream())
{
    // use the connection and the stream
}

This example takes a little explanation. For one thing, most people don’t know you can stack the using statements like this. Another thing is when the program flow exits the brackets for any reason both the connection and the stream will be disposed of.

Hopefully, if you have a well-designed connection class, the connection will close prior to being disposed of. In this case, there’s no need to do anything else. This is how C# is meant to be!

Continue the Journey

Clearly, we’ve covered a lot so far, but this is just the beginning. There are so many standards in C# that we can’t possibly cover them all in just one post. Thankfully, we have tools such as Visual Studio to help us while we’re coding.

But there’s an even more powerful way to check your work before it goes out into the wild. Tools like CodeIt.Right offer much more and are continually on top of the latest standards and conventions. Check out some of the Rules Explained posts to see why.

Learn more how CodeIt.Right can help you automate code reviews and improve the quality of your code.