Was the var keyword really only brought out to shorten your syntax? Or have the VB language guys got their way in C#? What type of variable is it? All will be revealed.
Also called: Implicitly typed local variables
The var keyword – in VB
I have heard many an argument about this new addition to the C# language. One of the main debates being: It’s so VB like, It reminds me of Dim. So this is all I am going to say about its use in VB (and only because I think if VB programmers use it may make their code just a little better).
Its use in VB is slightly different to that in C#. This is because VB has always had an unknown type keyword (dim), so you have to explicitly “turn on” the functionality by using the “Option Infer On” at the top of your module. So to finish off for VB: To use this functionality turn it on and the declare your Variable like so:
Dim MyStringVariable = "hello world"
When hovering the mouse over MyStringVariable you will notice the tooltip text says Dim MyStringVariable As String. So you will not be able to do your usual VB thing and change its type later on to an int!
The var keyword
First of all to ease all your minds the var keyword is not evil VB code creeping into your C# IDE! It is strongly typed (which means that you cannot put a string into it and then later on change its type to an int).
It must not be confused with the object data type – it is also not an object. So what is it? It is whatever you want it to be
when declaring the variable. So if you type:
As you can imagine, some declarations can become quite long.
In line 1 you are saying: I am declaring a List of strings and I want to assign it to a list of strings object. Using the var keyword you are saying that I have a variable and it is a list of strings – you don’t have to say it twice. To strengthen this point: You cannot declare a var and then initalise it later. When using the var keyword you have to initalise it on the same line (Only exception is that you cannot initalise it using a collection initaliser). And you cannot initalise it to a Lamda expression.
The following lines of code are errors and will not compile:
All this effort in not only to save me from typing out the extra three chars in the word "string." There are actually types in C# that have no name. These are called Anonymous types. They are not any conventional type of object, but they do exist and you cannot initalise them without using the var keyword.
Example 1:
var Car = new { Manufacturer = "Audi", Model = "A4", Year = 2006, Colour = System.Drawing.Color.Blue };Console.Write(Car.Colour + " " + Car.Manufacturer + " " + Car.Model + " " + Car.Year);
As you can see from the (pretty useless) example above that we now have an object which we don’t know what its name is, but we have assigned the variable Car to it, and Car has all of the valid properties to it. However it will print out to the console:
Color [Blue] Audi A4 2006
Example 2:
A more useful example would be when querying an Object / XML / Anything using Linq.
var Articles = (from a in context.Articles orderby a.CreateDateTime descending select new { ArticalTitle = a.Title, Created= a.CreateDateTime }).Take(5);foreach (var article in Articles ){ string s = article.ArticalTitle; DateTime d = article.Created;}
So instead of bringing back the SQL whole object (in this case) a new anonymous object is created and returned. This I suppose was the main reason for the keyword.
Conclusion
Using var should be embraced by developers worldwide. There is no way to misuse this keyword. It is always good! The only conceivable reason not to use it would be if you don’t know the data type of the “RHS” of the =. This could possibly lead to reading issues ... but not really. Ie:
var x = 0;
you know 0 is an int. Therefore x is an int. However
var c = MyObject.variable;
(a newbie to the project may not know what datatype variable is of class MyObject). Developers working with the project should know. Moreover, correctly named variables should sort out this issue. Example: Without knowing anything about a class we could guess that the property StartDate is a type of System.DateTime. Else whip the developer if it's a string!!!
Our community of experts have been thoroughly vetted for their expertise and industry experience. Experts with Gold status have received one of our highest-level Expert Awards, which recognize experts for their valuable contributions.
A value type can never be null, so the point is moot. A nullable value type would work, though.
The "problem" with default--and mind you I really have no issue with default in general--is you have to know what the default value for the thing you are assigning is when you write it. The list isn't exhaustive, so it's not that big of a deal.
Our community of experts have been thoroughly vetted for their expertise and industry experience. Experts with Gold status have received one of our highest-level Expert Awards, which recognize experts for their valuable contributions.
But in reality, do you have to *know* what the result of using default on a type is? Can you just not check for type to default(type) equality [or inequality] by using:
Our community of experts have been thoroughly vetted for their expertise and industry experience. Experts with Gold status have received one of our highest-level Expert Awards, which recognize experts for their valuable contributions.
Comments (15)
Commented:
Yes, that works for reference types but does not give you a *strict* value type; e.g. -
Open in new window
Which could just be splitting hairs but also why I prefer using the default keyword.-saige-
Commented:
The "problem" with default--and mind you I really have no issue with default in general--is you have to know what the default value for the thing you are assigning is when you write it. The list isn't exhaustive, so it's not that big of a deal.
Commented:
Commented:
But in reality, do you have to *know* what the result of using default on a type is? Can you just not check for type to default(type) equality [or inequality] by using:
Open in new window
As you have attested, the list is not exhaustive and, for the most part, is intuitive.Can I blame my last example on poor coffee intake? ;)
-saige-
Commented:
Open in new window
I agree, it's mostly intuitive: number types are all zero, and reference types are null.
View More