Why does ReSharper want to use 'var' for everything?

Question

I've just started using ReSharper with Visual Studio (after the many recommendations on SO). To try it out I opened up a recent ASP.NET MVC project. One of the first and most frequent things I've noticed it suggesting is to change most/all my explicit declarations to var instead. For example:

//From This:
MyObject foo = DB.MyObjects.SingleOrDefault(w => w.Id == 1);
//To This:
var foo = DB.MyObjects.SingleOrDefault(w => w.Id == 1);

and so on, even with simple types such as int, bool, etc.

Why is this being recommended? I don't come from a computer science or .NET background, having "fallen into" .NET development recently, so I'd really like to understand what's going on and whether it's of benefit or not.

Answer 1

One reason is improved readability. Which is better?

Dictionary<int, MyLongNamedObject> dictionary = new Dictionary<int, MyLongNamedObject>();

or

var dictionary = new Dictionary<int, MyLongNamedObject>();

Answer 2

There is no technical difference, if you use var, the type is implied by the compiler. If you have a code like this:

var x = 1;

x is implied to be an int and no other values can be assigned to it.

The var keyword is useful if you change the type of the variable; you then only have to make one change instead of two:

var x = 1; --> var x = "hello";
int x = 1; --> string x = "hello";

Answer 3

I personally prefer to turn this suggestion off. Using var can often improve readability; but as you mentioned, it sometimes reduces it (with simple types, or when the resulting type is obscure).

I prefer to choose when I use var and when I don't. But again, that's just me.

Answer 4

I disliked this as well.

I dont want this to turn into a debat on the use of Var, it has its use's but should not be used everywhere.

The key thing to remember is re-shaper is configured to what ever coding standards you want.

Edit: http://stackoverflow.com/questions/737835/resharper-and-var

Answer 5

ReSharper recommends var because it tends to unclutter object creation.

Compare these two examples:

StringBuilder bld = new StringBuilder();

var bld = new StringBuilder();

It's just a shorthand that is supposed to be easier to read.

i think it's fine when you create new objects explicitly with "new". In your example however, it might not be obvious if the classes were not named properly.

Answer 6

The var feature of .Net 3.0 is just type inference, which is type safe and often makes your code easier to read. But you don't have to, and can turn that recommendation off in resharper if you want.

Answer 7

What ReSharper suggests is clearly overuse of the var keyword. You can use it where the type is obvious:

var obj = new SomeObject();

If the type is not obvious, you should rather write it out:

SomeObject obj = DB.SomeClass.GetObject(42);

Answer 8

BTW, ReSharper draws a distinction between 'you might want to apply this suggestion to your code' and 'your code is broken, want me to fix it?'. The var keyword is in the suggestion category, along with things like "invert if to reduce nesting"; you don't have to follow it.

You can configure how annoying each of its alerts are through the Options dialog, or directly though the popup menu for that alert. You can downgrade things like the var suggestion so they're less prominent, or you can upgrade things like the 'use extension method' alert so it shows up as an actual error.

Answer 9

The var keyword was introduced in C# 3.0 - it allows us to forget about specifying our type explicitly.

There is no real difference to whether you use

MyObject foo = DB.MyObjects.SingleOrDefault(w => w.Id == 1);

or

var foo = DB.MyObjects.SingleOrDefault(w => w.Id == 1);

except pure readability and less chance for error.

It seems like a clichéd example, but say the following may help your understanding:

var myInt = 23;

returns an int type, whereas

var myInt = "23";

returns a string type.

MSDN reference

Answer 10

There is no technical difference (as eWolf pointed out). You can use one or the other, the generated CLR code will look the same.

In my opinion the main benefit is that this tends to force you to use better variable naming. In your example 'foo' is a pretty poor choice for a variable name.