Thursday, August 21, 2014

Var

Introduction


Sometimes I get lazy. Sometimes I get so lazy, I write a blog post with a 3-letter title. Sometimes I'm so lazy, I don't want to specify the type of a variable in the declaration so I use the keyword var and let the compiler determine the type for me. Yeah, I'm that lazy. Bow down all ye wannabe lazy folk and worship my laziness! The C# keyword var is my friend and my lazy-enabler, so let's discuss it today.

Details

First, a quick sample:

var thingy = new List<int>();

Normally the type of our variable would be List<int>, so you'd see that on both the left and right side of the = sign. However, the var keyword lets us implicitly set the type of the variable based solely on what's on the assignment side of the equation. Some of you might think "i hate stupid dynamic types; compilers and strong types are here for a reason!". Well, I agree with you, and guess what? var variables are in fact strongly typed! You get full intellisense on them in the Visual Studio editor, and the compiler determines the variable type and enforces it at compile type just as it would any other strongly typed variable.

Why?

Why might you want to use var in your own projects? Laziness is the best reason I've got. Let's say that later on you want to change the type of thingy from List<int> to List<long>. If you used var, you only have to change code on the right side of the equation. I know it's a small benefit, but like I said, I'm lazy and I think nearly every good programmer is in some fashion lazy. Less maintenance = more time for the beach! (or for you hardworking folks, more time for new features I guess).

It's also great for saving some typing in foreach loops. Check out this sample:

foreach (var item in bob.Possessions)
{
Console.WriteLine(item.ToString());
}

In this sample, maybe bob.Possessions is a collection of objects of type Possession, but hey it really doesn't matter. The key takeaway here is you don't need to know the exact class name to start up your foreach, and you've saved yourself some typing.


var is indeed for us lazy folks!

Why Not?

var isn't good for everything. I hate to use an incredibly abstract example, but this is about all I can come up with at the moment: Pretend you have an interface called IRepository, used to provide common methods for storing objects "somewhere". You have a class called MongoRepository that implements IRepository and stores your objects in MongoDB, and you have a class called SqlRepository that implements IRepository which stores your objects in SQL Server. Now if you have something like this currently in your code:

IRepository repository = new MongoRepository();


you wouldn't necessarily want to change this to use var. The reason is is because you have an interface that your concrete implementations must realize. Your local variable, being of type IRepository, enforces the contract (interface) but not the type (MongoRepository). If you instead use var, the type of your local variable will be MongoRepository instead of IRepository, which kind of decouples the class from the interface in an abstract sort of way and makes your code less resilient to change.

One more potential drawback: some people might find your code more confusing. Not me personally, but some people. I just find the code more succinct.

Limitations

var variables must be method scope.
var variables must be initialized where declared.

What's Next?

Lookup how to use var with LINQ!
Lookup how to use var with dynamic! (covered in a previous blog post).
var with a using statement is the bee's knees!

Resources

Implicitly Typed Local Variables

No comments:

Post a Comment