Anyone found a use of "var" other than for LINQ?

Question

Just curious. I'm about 99.999% sure there is none...but anything?

EDIT: These are OK answers (saving typing time or making the code less verbose for "readability"). I guess I should have clarified what I meant by "use" - some construct/design that couldn't be done without "var" .

Answer 1

I use var all the time-- especially when the class name is very long.

It doesn't post a problem for me because my methods are usually named in such a way that by just taking a glance of the name, I can infer the type.

And if I can't, I will use the VS 2008 intellisense to help me, or I just use Resharper var=> class name converter to convert it to the explicit name.

Another case I find a great use of var is in a foreach loop:

foreach(var id in idList)
{
  // do what you will here
}

Answer 2

Whats better in terms of readability?

AReallyReallyLongBusinessObjectName obj = new AReallyReallyLongBusinessObjectName();

OR

var obj = new AReallyReallyLongBusinessObjectName();

I say in terms of readability because using var has absolutely no impact on your app seeing as the two statements generate the same IL when compiled.

Response to edit: there is nothing that requires you to use var (other than anon types) - its just syntactic sugar.

Answer 3

Yes, I use it all the time while creating objects for class with long name and in foreach loop

EDIT : I don't think var could play major role in design or in any construct... because it can only be used in locally i.e within method or in scope.

Another major restriction of var is you can not use it as method parameter or as a return type. You even can not declare it as field in class. It means we can use var just to save typing time or making the code less verbose for "readability" and with LINQ

Answer 4

I use it in foreach loops very often:

foreach(var item in collection)

Answer 5

var is mostly useful for anonymous types (you cannot create one without it). I have also seen others use it to reduce typing and redundant type information through type inference.

I personally find that it can hurt readability when it is used to reduce typing - remember that you spend 1% of your time writing the code and 99% of the time reading it.

// the compiler may be able to infer the type
// of "foo" but I certainly cannot without 
// viewing the implementation of "doSomething".
var foo = doSomething();

Edit: The main thing to remember (and this is common to all matters of coding style) is that you need to choose a style and use it consistently. As long as you like it and have a reason for using it that you feel is sound then you have won the battle :)

Answer 6

How about anonymous classes?

var mySomething = new { Name = "Hello", Age=12 };

Answer 7

My favorite non-LINQ usage is in conjunction with foreach. Specifying the type explicitly instructs the compiler to do a cast if necessary, while simply using var is a simple way to ensure I really have the item type I think I have.

Answer 8

I find it invaluable in prototyping, it lets me quickly store results from functions / properties and also enables me to adjust the return types from those functions with less cleanup afterwards. It's a (wee) bit like an interface for the methods, it lets me worry less about the concrete return types and more about the intent of the method.

As others have mentioned it's also nice to use when initializing new instances of objects; having Foo foo = new Foo(); is redundant. var foo = new Foo(); is just as readable, even better if there's multiple declarations...

var connString = BuildConnectionString();
var sqlConn = new SqlConnection(connString);
var commandText = BuildCommandText();
var sqlComm = new SqlCommand(commandText, sqlConn);

vs.

string connString = BuildConnectionString();
SqlConnection sqlConn = new SqlConnection(connString);
string commandText = BuildCommandText();
SqlCommand sqlComm = new SqlCommand(commandText, sqlConn);

Answer 9

When using MVC and having a client controller to return all your ajax requests, you will pretty much always use a var, because with an anonymous type you can only send the data needed by the application back to the client.

var response = new { var1 = "bla", var2 = "foo" };
return JSon(response);

Answer 10

I've read somewhere that it's recommended that you use "var" in cases where you're calling code in a module not written by you, and that returns an object who's type is subject to future changes. If you were to write a wrapper to that external module, and you would only forward the result, than using var to temporarily store it would make your code still valid if/when the data type returned by the external call changes. Also, if you know that this result is some kind of collection, but again, not of a particularly stable kind, assigning to var and then iterating could still work in the event of further change.

Answer 11

I use var for nearly every assignment to a local variable. This really limits the amount of code changes I have to make if a particular method's return type changes. For example, if I have the following method:

List<T> GetList()
{
    return myList;
}

I could have lines of code all over the place doing local variable assignment that looks like this:

List<T> list = GetList(); 

If I change GetList() to return an IList<T> instead, then I have to change all those lines of assignment. N lines of assignment equals N+1 code changes if I change the return type.

IList<T> GetList()
{
    return myList;
}

If, instead, I had coded like the following:

var list = GetList(); 

Then I only have to change GetList() and the rest will be verified through compilation. We're off and running with only one code change. Granted, the compiler will complain if there was code depending on list to be a List<T> and not an IList<T>; but those should be fewer than N.