C# - Do you use "var"?

Question

C# 3.0 introduces implicitly typed variables, aka the "var" keyword.

var daysInAWeek = 7;
var paul = FindPerson("Paul");
var result = null as IPerson;

Others have asked about what it does or what the problems with it are:

• http://stackoverflow.com/questions/527685/anonymous-types-vs-local-variables-when-should-one-be-used
• http://stackoverflow.com/questions/209199/whats-the-point-of-the-var-keyword
• http://stackoverflow.com/questions/41479/use-of-var-keyword-in-c

I am interested in some numbers - do you use it? If so, how do you use it?

1. I never use var (and I never use anonymous types)
2. I only use var for anonymous types
3. I only use var where the type is obvious
4. I use var all the time!

Answer 1

3 - I just used var in a situation where it was obvious. The code looked something like this:

List<ErrorCodes> errors = AttemptMethod();
foreach (var errorCode in errorList) {
    // error handling code
}

Answer 2

While using var makes writing code faster, I find myself explicitly typing my variables, still. Obviously you have to use it for anonymous types, so I'll use it there.

Hence, my answer is: 2

Answer 3

4 - I'm a var whore, I use var everywhere.

The only time I don't use var is when I'm defining a new method/ class so I don't have to change it from object later on.

I find that var makes my life a lot easier when I do refactoring, especially when used within foreach loops.

Answer 4

I'm going for 3.

There are times when its kind of silly, and there are times when it makes sense.

If you're using it to replace say int, then it doesn't make much sense. You're not really benefiting, your using var just to use it, it's still three letters. If you're using it to infer an iterator or for a LINQ query or when you know what the method returns and it makes the code fit in the visible area of the code editor, cool.

Not mention the fact that if you're experimenting with LINQ and you keep getting compiler errors because your query goes from returning an IEnumerable<T> to IQuerable<T> to List<T>, then you're wasting your time.

Honestly, If you've ever used languages (like C++) which don't have type inference (not including TR1) it can make code where you use vectors painful to read because you send most of your time scrolling the code into view.

EDIT: Yes, in TR1 the C++ team re-purposed the auto keyword, let rejoice in the love!

Answer 5

Yes, definitley. Consider this:

Dictionary<int,Tuple<int,string>> items = new Dictionary<int,Tuple<int,string>>();

and then this:

var items = new Dictionary<int,Tuple<int,string>>();

The latter is much better IMO. For a start it doesn't require a scroll bar to be viewed!

I'm probably a 3.5.

Answer 6

I'm more of a type 2 guy - for clarity when reading code, I prefer to explicitly state the type whenever possible. Sure, in the IDE we have Intellisense and all - but how about on a printout?

Whenever possible, try to be as explicit as possible - makes reading code easier for other guys who come in and have to understand your code later on.

Marc

Answer 7

I`d like to use it whenever it's possible(because I do not use it frequently), but is there any performance problem?

Answer 8

I've read/heard a lot of people advising that you shouldn't abuse var because the type is vitally important to code readability.

For example:

IFoo f = GetMeSomething();
DoSomething(f);

Using var supposedly makes it less readable:

var f = GetMeSomething();
DoSomething(f);

Now we don't know what f is, which is supposed to be bad.

And yet no one would ban function composition:

DoSomething(GetMeSomething());

The sky doesn't fall in every time someone does that. Also lambdas have built-in type inference:

list.ForEach(f => DoSomething(f));

So it may be that over time, people get used to the idea of using var by default and only avoiding it where there really is a good reason.

Or maybe it will be like "Methods should only have one exit" and hang around in coding standards for decades, for no good reason. Another one of these is "Lambdas should be no more than two lines long."

Personally I hardly every use var but only for "cultural" reasons (i.e. to avoid starting arguments), because the benefit is usually minor. For example, someone said above that there's no point using var instead of int because they're the same number of characters to type. Not so - if you have a bunch of code using int and later you decide to use double, it saves you a few seconds of search and replace!

Answer 9

i'm a 3 as i think that writing var is muuuch more convenient than having ultra long declarations with namespaces, multiple generic definifinitions and so on.

Answer 10

I'm only using var when I dealing with LINQ.

Answer 11

Somewhere in between 2 and 3. It's handy for some things regarding to data-access (e.g. entity framework). But, when ever possible I try to use it where the resulting type is obvious or at least you get it with a small amount of thought...

Answer 12

Actually, i'm more of a 2.5 guy.

2.5 - I only use var when the type isn't very obvious, or when I don't really need to think about the type.

I seem to use it primarily with LINQ to SQL. ie.

var results = from blah ....

Honestly, i'm not a big fan of big honking types. You can use a using to alias them, but that's doing the same thing.

And I absolutely HATE interfaces as variable types.

Answer 13

I'm a 2.

I only use var when dealing with LINQ to SQL.

Otherwise I don't really like making the compiler decide the type for my object.

Answer 14

I think I am a 2.5

I usually only use var for anonymous types but I also use it sometimes for Linq queries where the resulting type may change if I change the query later. Then I also use var so I have less refactoring to do when I change the retunr type of the select.

Answer 15

3, but I find 'obvious' to be highly subjective.

I've found most devs are ok with:

var sb = new StringBuilder();

But get annoyed by:

List<MyType> items = GoGetMyTypes();

foreach ( var item in items ) {
    //they don't know what item is here without intellisense.
}

Answer 16

Personally, I only ever use var for anonymous types. Basically, when I have to use var rather than an explicit type.

I dislike the use of var for implicitly inferring types which can just as easily be explictly declared, i.e. :

// Yes, it's obvious that i is an int!
var i = 10;

// But why not use "int i = 10;".  Just as many characters to type!
int i =10;

Also, there are some situations where typing of the var is not obvious, at least not to me, i.e.:

var q = SomeFunkyMethodThatReturnsSomething();

Hmm.. Now I have to look up SomeFunkyMethodThatReturnsSomething in order to find out it's return type before I can know what q will be. Yes, intellisense can help, but I shouldn't have to rely on that, nor should I have to perform additional steps in order to know what type q is.

Here's another (admittedly contrived example) of where this kind of typing can be confusing:

double d = 0;
var e = 0;

I don't know about you, but this makes me have to do a double-take (excuse the pun!). At first glance, due to the "code noise" if you like, it's not immediately obvious what e is here. I have to stop and think before realizing that e is an int.

Answer 17

I'm at least a 3 (force of habit means I still type the type sometimes), for the reasons people have given above.

Having played with functional languages such as OCaml and Haskell, I'm quite happy with type inferencing - if anything C# doesn't go far enough!

Answer 18

1# here - aka "bah humbug, you crazy kids and your vars". back in my day we typed out all our types and we liked it just fine

Answer 19

I'm in camp #3. I prefer to use var when I feel it's obvious what the type is going to be. If I feel there is some ambiguity over it, then I'll be explicit.

Answer 20

VOTE : 3

But let me state that I explicitly define my variables. I let Resharper convert them to var when I clean the code. I am just not used to type var, but I use them ;-)

Answer 21

5) I only use var where the type is NOT obvious.

When using various interfaces (whether the interface type OR an abstract type), and if you even care to know, it can sometimes be a burden to determine at design time what type will be inferred and where it can be used down the line. One would hope the Liskov Principle would come into play here, but it doesn't always unfortunately.

I read on an MSDN blog (the specific one escapes me) to use var when you're not sure polymorphically what type will be coming back. So basically, if I know what it's going to be, and I'm not typing a bunch of generic type details out (as in Jonathan Parker's example above), then I use the specific type. Otherwise, I use var.

My humble $0.02

Answer 22

I'm a 3.5, or higher. There are some times that I don't use var, so I'm not quite a 4. I believe that redundancy is a worse problem than any readability hit. The redundancy that comes from restating the type over and over makes refactoring harder and just makes the code base more difficult to work with. There is already enough friction for developers to overcome as it is.

Answer 23

I'm a 1-2. I think the simple case is that over the longer term, the var keyword will have been seen to have weakened the language, because it inherently makes code harder to read, especially after 1 or 2 years. I've worked in several software houses already which have added var as a prohibited keyword, except in very specific instances, to enforce explicit declaration, and to improve long term readability. It should really be only used when your not sure when the rvalue return type is going to be, and intellisense doesn't immediately offer it up. Otherwise use sparingly.

Answer 24

I tend to use a lot of generics in my code,...as well as lambda expressions, and the like.

So yes, I use var everywhere I can.

Once you get over hungarian notation, switching to var is easy.

Answer 25

I use var with anonymous types in LINQ and in production code sometimes when the type is obvious from right side value.

In some tests and prototypes the var is very handy.

Answer 26

3 for me. I use it everywhere the type is obvious. Why on earth would anyone want to type the same thing twice, especially when generics with multiple type parameters are involved? :)

Answer 27

My standard is that the only time var is okay is with LINQ, anonymous types, and

var foo=new Something();

This is not okay:

var bar=GiveMeSomething();

Answer 28

I use var whenever possible. I find this invaluable for refactoring. I can change the return type of a method without having to change any of the methods that call it (in most cases).

I had an issue like this with code that returned List. The recommendation from FxCop was to use Collection or ReadOnlyCollection for these. Before making this refactoring, I first had to change all the explicit references to use var. Then, changing the return types made little or no change to the calling code.

Answer 29

We've discussed this at my current job, where the feeling among some is that it's OK to use var where the type is immediately obvious.

I seem to be in the minority, but I disagree. Why? Because I think having a type doesn't actually convey that much information. The name of the variable conveys much more. The real problem with using var everywhere is that it uncomfortably reveals the fact that you're choosing crappy names for your variables.

The solution, of course, isn't to ban var; it's to allow var everywhere and fix the variable-naming problems that become obvious when you do.

Answer 30

I use it only in LINQ queries, because i don't have to check the return type. Sometimes i use var in foreach loops, because of same reason. Otherwise is better using types.

Answer 31

I'm a huge fan of var simply because it looks so much nicer.

We work all the time to reduce repeated functionality (refactoring) but people seem to support this repeated declaration of types. Apart from convention, there's no need to declare the type on both sides of the equals sign.

var things = new List<int>();
List<int> things = new List<int>();

I prefer to use var when I can.

Having said that, I'm now working in an environment where a support team need to quickly analyse code and apparently do so in text editors rather than booting up Visual Studio. Therefore they have no Intellisense. Using var definitely doesn't make things clearer for the support team; if programmers are used to seeing the type declared first then they may be confused, especially when working under pressure at 3am. So I do see an argument for avoiding the use of var.

Answer 32

To some extent I think that as developers we look for a nice rule that we can apply across the board.

The correct answer to the famous "var debate" is that it should be used when appropriate. We're paid the big bucks because we can determine when to use things such as "var" and when to avoid using them.

I believe that the use of "var" can be more extensive than just for anonymous types - but using it absolutely everywhere suggests that not enough thought is going into its use.

Answer 33

2 - I only use var for anonymous types.

In many cases the use of var makes the code less readable, especially when used to store method results.