Type/Namespace alias conventions in C# [closed]

Question

Are there are any established naming or coding conventions for defining namespace or type aliases in C#?

For those who are unaware, the C# language has a feature where aliases can be defined local to a file for namespaces and types. This can be useful when there are naming conflicts with third party libraries as well as for shortening type names within your code. Below is an example of what it looks like.

using Forms = System.Windows.Forms;

Most of the examples that I've seen around the web tend to use unabbreviated capitalized names as aliases such as the alias Forms in the example above. In some places including the official MSDN page which explains example with an alias of colAlias for the namespace System.Collections. To make it more complicated there may be a preference for some to choose different guidelines depending on whether a namespace alias or a type alias is being defined.

In order to give some background for why I'm interested any guidelines with alias names I'll explain what I'm doing. In a recent project I began simplifying a pattern where I have several classes which inherit from a generic base class which accepts complex type arguments by using type aliases.

So using this technique the complex example below becomes the much more readable once type aliases are applied.

public class MyClass: MyGenericBaseClass<TripleLindyFancyAlgorithm<List<SomeValueType>>, List<SomeValueType>>
{
    public override List<SomeValueType> DoSomething(TripleLindyFancyAlgorithm<List<SomeValueType>> operation)
    {
        // ...
    }
 }

And below the must cleaner version using type aliases.

using Result = List<SomeValueType>;
using Algorithm = TripleLindyFancyAlgorithm<List<SomeValueType>>; // Note: cannot reference an alias within an alias definition!

public class MyClass: MyGenericBaseClass<Algorithm, Result>
{
    public override Result DoSomething(Algorithm operation)
    {
        // ...
    }
 }

Although this looks much more simplistic, it's easy to forget that an alias such as Result is actually just an alias for List and that there is no actual type called Result. In order to separate the concepts visually I'm considering following some prefixing convention similar to the use of underscore '_' before private members in order to help distinguish type aliases from actual types. Before I do so however I want to make sure that I'm not reinventing the wheel since maybe there already more established conventions out there.

Answer 1

Namespace aliases are not a common feature of most code bases - the last place when I have used it, the senior developer was unfamiliar with it, though having worked with C# for many years.

Since it is rare, conventions have not been developed for it.

I would say that if you are going to use aliases, discuss this with your team to create your own convention.

Several different ways I have seen aliases used:

• An acronym of the namespace. Usually the capitals in the namespace.
• The very end of the namespace - if plural de-pluralized.
• A descriptive short name.

Answer 2

I would only use aliases in the case of namespace conflict (i.e. only if I had to).

For me at least, any other use is just confusing and a distraction.

Answer 3

Personally, I would only use it to keep intelli-sense clean.

using StringBuilder = System.Text.StringBuilder;

If you rename types you open up Pandora's box for maintenance programmers.

Answer 4

The two most common cases for namespace aliases are:

1. I saw it and I use it (as a trend)
2. I port code from another language

For the first case, no comment. For the second one a good example is porting code from C and use namespace aliases for practicality like:

using i64 = System.Int64;
using u8 = System.Byte;
using u32 = System.UInt32;
using u64 = System.UInt64;

Even if you consider the above aliases as lazy programming, they help to avoid mistakes.

Answer 5

I think the people who are inclined toward not using them at all are giving the answer you asked for. That is the convention. This isn't to say that it can't be useful, but not using it remains the norm.

Answer 6

You could adopt a convention to use them for abstraction.

using Id = System.Int32;

This way you can easily just replace that line with

using Id = System.Guid;

at some point and no other code would have to change (assuming you didn't peeked through the abstraction to create dependencies on the actual type...)

Answer 7

I generally only use them when I need to use two similarly named classes in different namespaces, and don't want to fully specify the type in the code:

using xItem = My.Project.NameSpace.Item;
using yItem = Your.ThirdParty.Framework.Item;