According to MSDN, the definition of var is...

Beginning in Visual C# 3.0, variables that are declared at method scope can have an implicit type var. An implicitly typed local variable is strongly typed just as if you had declared the type yourself, but the compiler determines the type.

I find this interesting.  When I was first exposed to the var keyword, I mistakenly assumed it was for use with just LINQ queries like the code below:

        private void ExampleMethod()
        {
            var file = from d in System.IO.Directory.GetFiles("c:\\")
                       select d;
        }

Var is of type IEnumerable in the case above.  As it turns out, this is not the only use for var.  It can be used for any locally scoped variable. 

This is something as a former VB6 programmer I shudder to think about.  VB6 had a variant data type.  This was not only a bad idea, but it was horribly misused by inexperienced programmers.  Just to cover all the bases, it was bad for reading the code, and it was bad for performance.

The var data type in C# is different, it is not like a variant at all.  It is assigned the variable type from the result of an assignment.  Lets run a test:

        public static void TestMethod1()
        {
            var isAString = "ABC";
            Console.WriteLine(isAString.GetType().ToString());
        }

I would like to point something out.  Intelli-sense treated the isAString variable as a string as I was typing the Console.WriteLine function call arguments.  I am expecting to see String output to the Console.  It said System.String but close enough ;).  This tells us the variable is strongly typed.  The compiler inferred its type from the assignment.  This makes for some good variable declaration short cuts.  I am not sure if that is a great idea,but  If you couple that with a good variable naming conventions you might be ok.

Now let's try another test:

        public static void TestMethod1()
        {
            var isAString = 1;
            isAString = 2.02;
            Console.WriteLine(isAString.GetType().ToString());
        }

That code would not even compile.  In case you don't see it right away, I have created a var of type int and tried to assign a double value to it.  Let's see if this will work...

        public static void TestMethod1()
        {
            var isAString = 5/7;
            Console.WriteLine(isAString.GetType().ToString());
        }

I am not so sure I like this, no visible compile errors this time.  Lets see if it builds...  It does build.  Now lets see what the type is when we run it.  Ok so it creates an integer and it gets the value of 0. 

It would be good for temp or throw away variables.  Let's try assigning it to the return type of a function.  I don't think this would be a great idea. 

        public static void TestMethod1()
        {
            var isAString = getIntForTest;
            Console.WriteLine(isAString.ToString());
            Console.WriteLine(isAString.GetType().ToString());
        }
        public static int getIntForTest()
        {
            return 5;
        }

Sweet that code would not compile.  I really think allowing var to be assigned the result of a function would have been a bad idea, because it would make it more difficult to determine what the return type of the function was supposed to be.  I think they did a good job with this keyword.  As a developer with a little bit of experience everything I would have thought would be a bad idea does not work.  I hope the VB6 guys are listening.

Alright enough blogging for tonight.

Code Happy,

Bill

Today is a busy day for posting.  I have found that it helps get my thoughts in order. It also allows me to work on my communication skills.  I am a very verbal person and putting things on paper is sometimes difficult.  I have found in Visual Studio 2005 that you cannot go to definition to another language.  I am unable to go to definition from a c# project to vb.  I don't think this a problem that will hit a lot of people.  I am developing my current project in vb by request, and the testing framework is in c#.  I have found another oddity.  It seems that when you make changes in the vb code you have to remove and re add the reference even though i have a project reference.  It is very interesting.  

****EDIT******

So I have not found much evidence to support what I experienced.  My understanding is this should work with no issues.  I will keep digging and see if I find anything.

Remember to Code Happy,

bill

The originally article can be found here:

http://blogs.msdn.com/dinesh.kulkarni/archive/2008/08/10/net-fx-3-5-sp1-two-perf-improvements-linq-to-objects-and-linq-to-sql.aspx

Cast<T> break change.  The RTM version allowed for you to cast object that should have been invalid.  You could query and cast a float to an integer.   This is not allowed because of the possibility of data loss.

Standard execution time for querying a collection has been improved.  I understand the performance increase to apply to using Where and Sort.  However the way the article reads there seem to be improvements to queries not using Where or Sort as well.

Linq to Sql has fixed an error when caching identity based data.  Previously the query would be executed again even if the identity row was already in the cache.

A lot of my development at this time is leveraging LINQ to SQL, and LINQ.  These are both huge time savers and remove the tedium of writing that same old data access layer.  It allows you to spend some time learning some new patterns and working on writing solid code.  I think with these tools in our toolbox part of the data access layer problem has been solved.  They allow you to focus more on the application than the data. 

There are other features introduced into this problem space.  They target this problem as well and include the entity framework, and by extension the LINQ to Entities.  This gets the middle and front end developers more into domain based programming instead of a one to one class mapping of objects from the database.  Go forth and abstract.

As always Code Happy,

Lord Coden