Casing - Modern C# Standards and Conventions

This article is part of a series describing Modern C# Standards and Conventions. A list of the other articles in this series can be found below.

Contents

If you feel there is something else that should be included here, please drop a comment below, or better yet send me a PR.

Casing Techniques

To get the ball rolling, you need to understand the names we use to describe casing techniques.

Camel Casing, also known as lower camel, is when the first letter of the first word is lower case, but all other words will have an upper case first letter (in some strange way, I guess this is like a Camel’s humps?). As a simple example:

fooBar

Pascal Casing is almost identical to camel except the first letter of the first word is also upper case. You may sometimes see this referred to as Proper and I’m sure a slew of other words to express the same intent. As a simple example:

FooBar

With those two key techniques out of the way, we should easily be able to define which cases in your code should be camel, which should be pascal, and which case should be upper (all uppercase).

There are some Microsoft guidelines to casing if you’re interested, but here’s the gist of it:

Camel

  • Private members
  • Method parameters
  • Local variables

Pascal

  • Type names (class, enum, struct)
  • Namespace names
  • Public, Internal, and Protected members
  • Generic Arguments (the declarations, i.e. Func<TResult>)

It’s increasingly common to see constants declared in Pascal case, however, upper-case declarations are also ok for const

Acronyms

So the above describes how to case your words, but what do you do about acronyms? As it turns out, it’s pretty simple though probably not entirely what you expected:

  • For 3 letters or more, treat the Acronym as a normal word (i.e. var xmlReader = new XmlReader())
  • For 2 letter acronyms, use all upper, except in the case of a well known acronym such as Id.

For the most part you should avoid defining Acronyms in your code. There is almost no restriction on member/type name length, so describe your code’s intent. Not everyone in your company may share your knowledge of the domain. Not everyone using your software may consider an acronym you used during your computing degree as common as you do.

Write code so that it’s easy to read. For everyone.

If you need the code obfuscated, use a tool to do so, don’t be a tool.

Next

The next article in this series is Underscores.

Written on August 4, 2015