CodingSmarts

The stuff that good code is made of

Anonymous Types in C#

with one comment

This is the second in a series of articles about the language and framework features that make Microsoft’s Language Integrated Query (LINQ) possible. The goal of this series is to understand the individual elements of a LINQ statement without the C# syntax sugar hiding the details of how it works.

An anonymous type is the declaration of a class signature at the same time of its value initialization.

var person = new {FirstName="Bubba", LastName="Jones"};
Console.WriteLine(String.Format("Hello {0} {1}", person.FirstName, person.LastName));

When the compiler processes the first line of this example it creates a new type that has two properties (FirstName and LastName). It gives this type a generated name that the programmer does not know. So how does the programmer reference an instance to a type that she does not know the name of? This is the situation the var keyword was designed for. The compiler knows the type name because it created it. It substitutes the anonymous type it created in for var, just as it would substitute in any built in type like string if the initializing value was a string. As can be seen in the second line of the example the resulting reference is strongly typed. You get an object with two properties whose data types have been inferred to be strings. If you are using Visual Studio you get intellisense for your newly created type as well.

I think a common reaction that developers have when they learn about anonymous types is “I will never have to write another data class again.” Unfortunately this is not the case. It is by design that these type definitions are unnamed, and its the programmer’s inability to explicitly reference these types that makes them almost useless outside of method scope. You can pass an anonymous type into a method as an upcasted System.Object type reference. A good example of this can be seen in the ASP.NET MVC bits where anonymous types are used to initialize Hashtables with a collection of named properties, but because you upcast and lose your strong typing to do this it requires the callee to use reflection to examine what properties exist in the anonymous type. This would not be a good option for passing around the data model of your solution. Anonymous types also do not support method signatures or inheriting from anything other than System.Object.

So if anonymous types are not a practical solution for your data model what can they be used for? It turns out that anonymous types are extremely useful when querying data and producing a result set that is either a combination of different types or a narrowing version of an existing single type. Try to think of it in the context of how you would write a SQL statement to return some records from a table in a database. Does your return always match all of the columns from a single table? Or do you sometimes only return some of the columns from a table, or do you sometimes return a combination of columns from two or more tables after a joining operation. How would you replicate this dynamic result in the strongly typed C#? Without anonymous types you have to create a class definition for every possible result you returned, or create huge classes that accounted for every result possibility. With anonymous types you can have the compiler create these classes for you as you need them, and when the compiler does generate them they only contain the properties you need for the desired result.

Written by Shawn Walcheske

September 25, 2008 at 10:46 pm

The C# var type and its usage

leave a comment »

This is the first in a series of articles about the language and framework features that make Microsoft’s Language Integrated Query (LINQ) possible. The goal of this series is to understand the individual elements of a LINQ statement without the C# syntax sugar hiding the details of how it works.

The var type in C# is a powerful feature that enables developers to write code in patterns that make the type safe C# look and feel more dynamic. This is an important enhancement to the language because it allows developers to create code that is more concise and maintainable. However if the var type is needlessly abused it will lead to sloppy code that developers will find harder to maintain.

In C# 3.0 and greater var is a special type that can only be used at method scope. The purpose of the var type is to signal to the compiler to implicitly type the variable based on its initialization expression. This means that even though the programmer did not tell the compiler the type of the variable the compiler is smart enough to figure it out on its own. This in turn means that the variable will still have all of the type safety that an explicit declaration would have.

To help understand the var type lets take a look a two simple code samples.

This first sample block uses an explicit variable declaration to create a string and then uses an instance method on that string to only display the first 3 characters.

string s = “Hello World”;
Console.WriteLine(s.Substring(0,3));

If you have been a C# programmer for any period of time this should feel very familiar. If you use Visual Studio to write the block above you would get intellisense for the Substring method because on the line above you told the compiler that s is a string, and strings have a Substring instance method.

Now lets take a look at an almost identical example, but this time we will use the var type.

var v = "Hello World";
Console.WriteLine(v.Substring(0,3));

If you were to type these two lines into Visual Studio you may be surprised to find that you will still get intellisense for the Substring method. This happens because when the compiler evaluates the first line it determines that the variable v is a string because of what you have assigned to it. Once the compiler determines the type of a var variable it is no different then if you had explicitly defined the variable yourself.

If you have a Visual Basic background you may be saying to yourself this looks a lot like a Variant. This is not the same thing as a Visual Basic Variant which relied upon late binding at run time to discover the type and methods of an instance. The compiler figures out v is a string and the executable code does not look any different than if you had declared v as a string yourself. There is no run time cost for using the var type.

Now that we have examined the two examples above I would like to recommend that you never write code like the second example in your C# life. I make this recommendation simply because it is a needless abuse of the var type. You know “Hello World” is a string so why not explicitly tell the compiler that it is a string. Being explicit is a good general rule to follow for all of the code you write not just for the use of the var type. When you are explicit it makes it much easier for the programmers that follow you (and future versions of yourself) to deduce the meaning of the code that they are reading. We are not compilers like C# and wasting brain cycles figuring out the implicit semantics of a line of code is not how you should spend your coding time.

You should limit the use of the var type to when it is required, primarily when you the programmer do not know the name of the type that your initialization expression returns, but the compiler does. This happens because of another C# language feature called anonymous types that I will write about next time.

Written by Shawn Walcheske

September 8, 2008 at 5:55 pm

Posted in The underpinnings of LINQ

Tagged with , , ,