Steve Fenton

<< May | June | July >>

Thursday, 3rd June 2010

Since it was introduced in C# 3, the var keyword has been the topic of much debate. This is my chance to explain why var is a positive addition, when used in the right context.

The main benefits of var are listed below - these are the main benefits and you may well be able to think of many more. Before we dive into the benefits, let's just note a quick warning. I am not telling you to use the var keyword everywhere. There are many placed you cannot use it (for good reason). Using var should make your code better, not worse - so you your super-developer sense to apply it where it is appropriate.

• It makes you name your variables better
• It removes the redundancy of declaring type both on the left and the right of the statement
• It is less brittle when it comes to change (examples below)
  
• You can't accidentally instantiate a null value (i.e. bool isTrue;)
• It reminds you to instantiate the variable closer to where it is used
  

Using a var still gives you strongly typed fields. You can't change the type of a field and it is all compile-time checked.

Point 3 in more detail

int storeId = 1;
List<Store> stores = GetAllStores();
Store firstStore = stores.Where(store => store.id = storeId);
StoreAddress address = firstStore.Address;

The method GetAllStores returns a list of stores. If it changed to return a List<SuperStore>, you would have to change this code - even if the SuperStore was identical to the Store object (for example, if you create an IStore interface and change Store and SuperStore to implement IStore...)

int storeId = 1;
List<SuperStore> stores = GetAllStores();
SuperStore firstStore = stores.Where(store => store.id = storeId);
StoreAddress address = firstStore.Address;

However, the following example would be more de-coupled and would not need to change.

var storeId = 1;
var stores = GetAllStores();
var firstStore = stores.Where(store => store.id = storeId);
var address = firstStore.Address;

Admittedly in this example the storeId and address are not affected by the change in this example, but they are shielded from future changes. This is a classic "closed to change" style of coding. Note that if we evolved from Store to IStore, we are protected even from that small change.

Further reading

MSDN Documentation -  http://msdn.microsoft.com/en-us/library/bb384061.aspx