I agree with most of what you've said here, but your Person person = new Person() example is slightly contrived (you say it "ttells me in 3 places i am dealing with a person"). You could name your variable whatever you want, so I don't think the fact you've chosen to name your variable Person should be part of your tally. A silly nitpick, I know.

Totally agreed man. vars are much cleaner, and you can still hover the mouse over them in VS and pick up what the type is if you're really interested.

It makes for quicker code writing, and cleaner code.

Wow.  Worst thing every invented?  Lazy programming?  I can understand how var could be abused, but I agree that it most cases it makes code much easier to read (and possible in the case of anonymous types).  It sounds to me like Mr. VarHatingDude doesn't really understand what the var keyword means or what it is for (differed type instead of inferred type?).  Some people are afraid of new things and things they don't understand.  And sadly, some people would rather say that something is "the worst thing in the world" than take the time to figure out how it works.

dim Person as new person()

;)

OMG, there is a VB lover here! :)

I am using var's since the beginning :)

I noticed there are roughly two reasons why people hate vars:

- they pay too much attention to what type a variable is, instead of _what_ it should do.

- they simply do not understand it, that's why they feel lost when dealing with vared code, hence the rant

If it's clear from the right hand side what the type is, use it, if it isn't don't.

I'd not use var in the following example:

Person selected = context.EmployeeSelector.Current;

[)amien

The very fact that we're talking about the var keyword in our dialogs about C# tell us that we're progressing toward an appreciation of less ceremony in C# code.  Nonetheless, 'var' is a vestige of ceremony.

I'd rather see the var keyword go away entirely.  Languages other than C# (etc) can deal perfectly well with:

person = new Person()

PS: The var keyword in C# was released in 2005 with the C# 3 spec and the C# 3 language service for Visual Studio.  We're coming up on the 4th anniversary of var, not the 2nd.

The first point rings very true. So many var haters I've met actually believe var is the same as a variant type from VB days; I try to explain that var is simply letting the compiler type out the type name instead of you, it still ends up being there it just saves you a few keystrokes.

People should only care if an object can do what they want it to, not how it does it; that applies to interface segregation all the way down to declaring variables of a fixed type.

I agree with Scott, why do we need var at all? Surely if a variable isn't declared yet and you want to use it, it should just be declared; why do we need to be explicit about it? Works for the dynamic languages, but I'm pretty sure there's nothing stopping a static language from doing it too (Boo comes to mind).

Personaly I am very careful with using var. I agree sometimes it improves readability. This is expecialy the case with linq, e.g.:

var customer = from c in CustomerController.GetCustomers where c.Gender == 'M' select c;

However, Derik's example of using var is, imho, a poor one:

var person = new Person();

The next step would be:

var person = PersonFactory.CreatePerson();

This should read:

IPerson person = PersonFactory.CreatePerson();

@Scott: I'm really not a fan of languages which don't require some kind of declaration to indicate that the variable is to be used. It makes it easy for mistakes to happen. This kind of issue was rampant through VB code, and it was so bad that most of the time people turned on option strict which forced the use of the Dim keyword.

I'll take var over nothing any day of the week.

If Microsoft had named var something different like 'def,' I doubt we would have var wars.

I find that when doing interface-based development, it is very easy to accidentally do compatible type casts where we do not want to. You might do

double x = window.GetZoomFactor(); // Returns int.

when you meant

int x = window.GetZoomFactor(); // Returns int.

If you had written

var x = window.GetZoomFactor(); // Returns int.

you would have increased the precision of your code.

Dale

Have to say I love VAR, more so when I'm working with annoying webservices, it makes life simpler and makes complete sense in a modern programming language.

People always complain when things change, hence the PHP group moves so damned slowly.

I agree that 'var' with simple types rarely adds much. However, if you are dealing with variables of a type that has a long name, perhaps a two-type generic in an assembly you don't have a using for, inside an expression, using 'var' can really help code readability. Which of the following is more readable and maintanable (assuming equally known context and that SomeFunc returns LongContrivedTypeName<OtherLongTypeName,EvenLongerAndMessierTypeName>)?

foreach(var item in SomeFunc())

{

// ...do magic...

}

or

foreach(LongContrivedTypeName<OtherLongTypeName,EvenLongerAndMessierTypeName> item in SomeFunc())

{

// ...do magic...

}

They are semantically identical, but assuming that you have some idea what the signature of SomeFunc is, the 'var' version is significantly more readable, IMO.

I follow the convention of using var when it is obvious from the RHS what the type of the variable is going to be, and declaring its type if it's not.

var x = new X();

vs.

X x = Y.GetX();

Still increases readability a lot when working with generics.

I'm with Martin Watts per his example.  I think it's useful to see that it's an interface in that example