Get Help:Ask a Question in our Forums|Report a Bug|More Help Resources
Last post Mar 30, 2010 07:40 AM by Rimbik
Mar 26, 2010 07:35 AM|LINK
When I first became engaged with the var keyword in C# there were lots of recommendations about using it onlyl for LINQ to SQL or other cases where it was essential. Now, over the last few weeks I'm seeing it on blogs, video tutorials and whatnot?
Mar 26, 2010 08:26 AM|LINK
var y = null;
In both cases there is no way how to detect the type of variables.
If you want to find out more about var keyword and how to use it then I suggest you to read some of my writings:
Mar 26, 2010 08:28 AM|LINK
In C# the compiler emits code in compliance with the type - so it is strongly typed.
var i = 10; // i IS INTEGER, not var!
Mar 26, 2010 08:30 AM|LINK
I find it mostly a matter of personal taste. I'm using Resharper myself which constantly nagged me about changing things to the var keyword so I turned that off. If I want to write var for something I want to be able to choose so myself. I try most of the
time still to use the class or interface for my variable but for Linq I usually use the var keyword as I don't want to think too much about what output type it'll generate.
Sometimes for very long statements or class names which I know can only be of one specific type I also use the var keyword as otherwise I end up with very long lines of code. As I said it's a matter of taste.
Mar 26, 2010 10:45 AM|LINK
I assume when you speak about var it is in C# context.
var is introduced with LINQ like:
var myMostLovelyFriends = myFriendList.Where(f => f.IsAbove50 == true);
the above you can also achieve by
List<Frirnd> myMostLovelyFriends = myFriendList.Where(f => f.IsAbove50 == true).ToList();
it is upto you what you want to do after getting the result, Say for example
if(myMostLovelyFriends.Count() > 0)
// here u just wante to know whether you have such friends or not thats all
so var is suitable, typecast with List<Frirnd> is not mandatory.
Mar 26, 2010 11:15 AM|LINK
I find it mostly a matter of personal taste. I'm using Resharper myself which constantly nagged me about changing things to the var keyword so I turned that off.
I find it puzzling that more people don't complain to the producers of Resharper about this. Like any company, they can get on the wrong track about something - they are simply wrong to suggest that "var" should be preferred for all local variables. The
"var" keyword was introduced for cases where the variable type is not obvious, such as for LINQ queries - it was not intended to be used for all cases.
Mar 26, 2010 01:03 PM|LINK
I believe it can be misused by slovenly and lazy programmers:
Try a maintaining a program where every type possible is replaced by var and see if you think it's easier, or harder, to understand and maintain the code.
Mar 26, 2010 06:50 PM|LINK
Thanks for the replies. The last few posts were along the lines of what I was getting at. Although, as I say, I appreciate the input of all contributions.
From a best practices point of view is the angle I'm coming from. I'm seeing the var keyword used a lot - outside of LINQ to SQL. I take it this is going against the grain of coding best practices?
Mar 26, 2010 07:14 PM|LINK
I think the issue is still very much up in the air. My two cents: unless the type is easy to read from the right hand side of the equals, dont var
var foos = new List<Foo>();
var complexThings = _mySerivce.GetCompicatedThingsByTonsOfCriteria(...);
Mar 27, 2010 01:21 AM|LINK
I guess someone needs to put the opposing view in.
Use var whenever you can! Why do I want to specify the type twice, once on the right hand side and then again on the left hand side? Doing things twice just make for a maintenance nightmare (to quote the general argument
No offence intended, but anyone who calls a method GetComplicatedThingsByTonsOfCriteria gets all the trouble they deserve unless it actually returns IEnumerable<ComplicatedThings> or similar. The method name should give me a good idea of the type being
returned. If I am uncertain then hovering over the var keyword in Visual Studio will tell me the type.
What sort of maintenance tasks does using var help? If you create a method ReturnStudentIds() then I would guess the return type is something like IEnumerable<int> or IEnumerable<Guid> or IEnumerable<string> (if you can't guess then you don't know your
codebase very well and you have much larger problems). Now you decide that you actuall want the students and not just the Ids so you rename the method to ReturnStudents() (that's a pretty easy refactor in VS). Modify the method as appropriate and change
the return type. Now in all your client code you have to fix the callers to handle the new return type. If I don't have to change anything to fix the type of the variable holding the returned value then that is just one less thing I have to do. Hooray!
What sort of maintence tasks does using var hurt? Ones where I have methods called GetData() or some other equally anonymous, non descriptive name. Eg the way to fix the code is to rename the method. Having to specify in every single piece of client code
what the return type of GetData is is just wallpapering over the real problem, the name was wrong in the first place. Someone made the maintenace problem by a poor choice of name, so fix the problem don't just create busy work.