The one thing about this "debate" that annoys me is that people keep talking about if var is good based on those simple examples:

var person = new Person();

How about those Anonymous Types where you can create your own classes on the fly?

var person = { Name = "Andrew", Age = 30, Address = new Address { Street....}};

Or when you create them by defining a few columns to select from a LINQ query?

It's frustrating to me that the debate seems to begin and end at whether it's readable given that you're only discussing whether you should use var to shortcut type declarations.

Anyway, that's my 2c.

Thanks

Pingback from  Dew Drop - June 25, 2008 | Alvin Ashcraft's Morning Dew

@Derik,

Sure, mate, but the debate makes it seem like the sides are that var is or isn't useful, and should or shouldn't be used based on that alone.

I may be wrong, but most of the time I don't see enough mentioned on anonymous types and the usefulness of var, outside of the shortcut scenario.

I just think the debate undercuts that.

I mean, don't get me wrong - I totally agree with what you've said in your post, it just frustrates me that not enough attention is paid on the other reasons var is there.

As a bit of a n00b, it's frustrating when anonymous types are a fantastic shorthand and utility, that more attention is paid to whether or not you should shorthand a declaration.

You did mention anonymous types and linked it, so maybe I'm just being a bit of a dork by bringing that up - but the debate makes it seem like that's all it's about.

I'm leaving var to just LINQ results and other anonymous types.  The difference is nil between

var s = "hi"

string s = "hi"

Because of the intellisense and tab I'm only typing "str[tab]" anyway.  And the bigger crime here is the "s" - there is no reason for short variable names, so this should have been "subject" - which also goes against the "less keystrokes" argument.

I've worked a good deal with Python, and if var were truly a dynamically typed variable I would say it had uses out side of LINQ results; just saving keystrokes though isn't enough for me to say it's a good idea elsewhere

var is not about saving keystrokes.

I think contributions to the "var war" may provide some insight to non-believers why some of us like it in more scenarios than most:

flimflan.com/.../ToVar.aspx

flimflan.com/.../LosingYourTypeReligion.aspx

I'm assuming you don't apply the rules to cases where you HAVE to use var, such as certain LINQ statements.

To me the big advantage comes when combining declaration and initialization, especially for generic types:

Dictionary<string, string> input = new Dictionary<string, string>();

Var supports the DRY principle here.

I think I'd also make an exception for local foreach variables. How often have you had to look up the item type of an enumeration just so you could specify it in a foreach statement?

foreach (PropertyInfo property in aType.GetProperties())

> // DO NOT USE var

> var person = someObject.GetPerson();

I have no problem with var here.  I don't particularly write code to express compiler and runtime constraints like data types.

I'd prefer that the var keyword be removed from the language entirely so that I could write:

person = someObject.GetPerson();

It's not the var keyword that is causing the implicit strong typing, it's the result of the call on the right hand side of the line of code - be it a call to the constructor or to a factory method.

I write code to express intent.

Derik,

If .GetPerson() doesn't return a Person or derived type, wouldn't your method naming be misleading?

Supposing your method names were accurate, I think var would be a valid option for the second example.

Chris

Would I read Jeff's post I thought to myself and came up with exactly the same rules you did here in this post. So, thumbs up from me.

Pingback from  Reflective Perspective - Chris Alcock  &raquo; The Morning Brew #123

Derek,

I was gonna blog the same thing... thumbs up from me too!

I think you nailed it...

Jay

I've fallen in love with var recently (R#4 has played Cupid).  

I like how some code becomes so much easier to read, such as:

var example = new ReallyLongClassNameProbablyWithGenericsToo();

I shy away from using var though when it comes to int, string, bool, etc.  I feel that it tends to obscure the intent in those cases.  Though I'm less and less hard about rules, and more inclined to ask "how will the person coming after me read this?".

(But ain't that a question with many answers!)

Nicely Explained

Pingback from  User links about "var" on iLinkShare

Here we are almost 2 full years since the var keyword was released to the wild, and only a few short