Use of the var keyword in 1.50

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
14 年 前
Hey - just updated to v1.50 and got a question on the use of the var keyword.
On windiffing 1.4 with 1.5 I found loads of instances of code like this:
List<Something> mySomethings = Manager.GoGetSomething();

having been replaced with:
var mySomethings = Manager.GoGetSomething();


I am really curious about the reason for this change - because to me it looks like "bad" code.
I thought that var was mainly intended for Linq queries and other scenarios where you dynamically create an anonymous type. My understanding is that the compiler infers the type - and it's simply a convenience for having to type out loads of class definitions - however, using it (like the above example) to store data from methods returning nicely typed collections seems wrong to me.

However this change from Lists to var seems to be implemented quite consistently throughout v1.50 - and with the quality of the code behind nop I am pretty sure that there must be real reason for changing this throughout...

Great work on the 1.50 version btw!
14 年 前
Becuase C# is a compiled language, there is no difference at runtime delcaring a variable as var vs a type.    Unlike a language like php where types are inferred at runtime (slow),  the compiler infers at compile time what type var is and outputs that type in the IL.   There are two main reasons ms did this:

obviously allows for the declaration of anonymous types (as in linq):

var anonEnumeration =
    from post in AllPosts()
    where post.Date > oldDate
    let author = GetAuthor( post.AuthorId )
    select new {
        PostName = post.Name,
        post.Date,
        AuthorName = author.Name
    };

And allows for cleaner code, for example:

Dictionary<string, List<SomeComplexType<int>>> data = new Dictionary<string, List<SomeComplexType<int>>>();

is much cleaner and easier to maintain as:

var data = new Dictionary<string, List<SomeComplexType<int>>>();

basically, both you and the compiler know what the type should be, so why not let the compiler do the work...
14 年 前
Hey,

Thanks for the reply - thou I think you might have missed my point slightly.
I am aware there is no performance hit (I also mention the compiler inferring the type in my post). My issue with the code is in fact the the readability and maintainability you also mention!

It is true that for code like your example where you go:
Dictionary<string, List<SomeComplexType<int>>> data = new Dictionary<string, List<SomeComplexType<int>>>();

then the use of the var keyword would be more concise and I agree we would be able to see what the type is (me and my compiler).
However if you look at my example - which I think is perhaps more common - where you call some other method to return something - then I don't think this is easy to maintain and certainly not very readable:
var data = GetData();

You see that and you have to ask yourself - what the heck is data? Is it a bird? Is it a plane?

So my initial point was that the var keyword was introduced because of Linq and the requirements of that whole wonderful world - but I just have a real dislike for the use of this outside Linq.
C# is a nice typed and compiled language, so why try and make it look like we're coding in Javascript?
Certainly does not make the code more readable to me.

The youth of today - I tell you, no respect for standards! ;0)
14 年 前
Agree with you that the second example is bad. I'm happy with the first.

This is a duplicate thread btw ;)
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.