What was part 1?  LINQ vs. LINQ was part 1, essentially.  As I was writing about using LINQ syntax versus extension methods, I started thinking about all of the other obvious syntactic sugars in C#.  While, personally, I am not a fan of the LINQ syntax, there are other sugary parts of C# I do not mind so much, and actually use quite a bit.  Today’s article is about a single keyword that seems to have a lot of C# developers (at least the ones I know) split down the middle of usefulness/annoyance.

var

Yup, that keyword seems to get a lot of opinions on why it should be used and why it should not be used.

For the uninitiated (e.g., those who are new to C# or have lived under a rock for three years), var is a shortcut to declaring identifiers in a particular scope.  Unlike JavaScript’s var, which is the only way to declare identifiers and all identifiers are not strictly typed, C#’s var is completely type-safe and bound at compile-time.

That is right, the C# compiler will infer the type of the value being assigned the identifier at compile-time and statically give the identifier the correct type.  There are some caveats:

• A value must be assigned to the identifier when the identifier is declared.  This is how the type is inferred.
• Once the type is determined, the type of the identifier does not change for entire scope of the identifier.
• The type will not change at run-time.
• If the value assigned to an identifier declared with var is ambiguous, the compiler will complain.  You will have to cast the value to a specific type to compile without errors.  (especially true for assigning a null value)
• var can only be used in a local method scope.  You cannot use it in member declarations in a class or struct.  It cannot be used as the return type of any method.

var is not a dynamic type (C# 4.0 does provide a dynamic type. I might go over that in a future article.).  An identifier declared with var has full Intellisense enabled.  You can even hit F12 on the var keyword of the identifier being declared and Visual Studio will jump you to the correct declaration in your project.  So, why would you want to use var?

• You don’t want to worry about identifier type declarations when changing type names or namespaces.
• Faster to type, no need to find the correct type to declare your identifier with.

Yup, pretty much pure sugar.  So, what would be the reasons to not use var?

• Lack of readability in some cases, especially if the type of the identifier is not evident in local scope.  Intellisense helps this greatly, but not everyone will be looking at code in Visual Studio.
• It is lazy.

Maybe laziness is not a problem for you (it certainly isn’t for me), but the readability is a problem for a some developers. Let’s consider a couple of examples.

Example 1:

public string ExampleMethod1(string arg1, int arg2)
{
    string arg2str = arg2.ToString();
    return string.Format("{0} {1}", arg1.Length, arg2.Length);
}

public string ExampleMethod1var(string arg1, int arg2)
{
    var arg2str = arg2.ToString();
    return string.Format("{0} {1}", arg1.Length, arg2.Length);
}

The above example has two methods that have the same exact result.  In fact, the MSIL generated for the above methods (sans the method name) is the same.  The example that uses var has good readability and is understandable from a quick glance.  The type inference is based on a local variable and the fact that it is assigned the result of the ToString() method gives it away that arg2str is a string.

Here is another example:

Example 2:

public string ExampleMethod2(string arg1)
{
    MyClass c = MyStatic.GetInstance(arg1);
    return c.ToString();
}

public string ExampleMethod2var(string arg1)
{
    var c = MyStatic.GetInstance(arg1);
    return c.ToString();
}

The example here that uses var certainly has a readability issue now.  Not knowing anything about the static method MyStatic.GetInstance() raises questions on what type c is.  The compiler knows and Visual Studio knows.  Moving your mouse over c in the return statement will reveal the correct type.  Also, the MSIL should be the same.  The compiler is 100% OK with this.  Your eyes, however, may have “trouble”.  Especially, perhaps, if I gave you just this snippet of code:

public string ExampleMethod2var(string arg1)
{
    var c = MyStatic.GetInstance(arg1);
    return c.ToString();
}

If this was all that was presented, you would have no idea what type c was, without being told.

var - love it or hate it, it does make coding faster and easier.  It is not always readable, however.  Personally, I am guilty of over-using it at times.

Are you a var-hater or a var-lover?

Tweet