By John Sonmez May 5, 2010

Do You Have a Case of var Guilt?

Ever since var was announced as a keyword for C# 3.0, I have had issues with it.

I know that it is strongly typed, but something just felt wrong about it.  It felt like some kind of an abomination.

Perhaps I just like to repeat myself = new Perhaps I just like to repeat myself.

Finally, I started using the var keyword because I don't know what the heck a LINQ query returns.  I just know that if I put var at my variable declaration before my LINQ query, it just works.  Then if I put var before my variable in my foreach loop, that just works too.

Reluctantly, I started using var but every time I did I would start to feel guilty.  Like I did something wrong.  Like I was a bad person.  Like I was writing strongly typed VB code.  I felt dirty.

Be clean my sons!  Throw off your shackles!

I contemplated the issue for a good long while.  It has been months that this var keyword issue has been eating me, slowly leaking into my code.  Then, I had an epiphany!

var is just an abstraction.  I don't need to know the type of variables as long as the compiler does.

There is no need to feel guilty when using var.  It is preventing the reader of your code from focusing on the types of the variables and instead focusing on the purpose of the variables.

I rewrote some code using the var keyword wherever possible to see if it decreased readability at all. (I took it to the extreme)

Admittedly, it looks a little strange.  But honestly, is it any more difficult to read than if I had put all the types in there instead of var?  Does that actually give you any useful information that helps you understand this code?  As long as my variable names are good I would venture to say that the readability is improved because anything that adds information that is not important to the code is a distraction.

Bonus: decoupling

As I was contemplating this issue, I realized something more than aesthetics pushed me to the var side of the force.  var reduces coupling in my code when I use it.

If I call a method that returns some object in my code but I hold the reference to it with a variable I declared using var, if that method changes to return something else with similar usage, I won't have to change the source code.  (I will have to recompile though.) In many instances the var keyword can serve as a bonus to slightly decouple your application in places where methods return concrete types.  Every little bit helps.

Anything that reduces your dependency on concrete types and makes your code more flexible while still catching issues at compile time instead of runtime is good in my book.

Hinging on the IDE

There is one caveat here.  This all depends on the IDE.  You have to have intellisense and auto-complete, otherwise this whole thing falls apart.  I don't need to know the underlying type because I can just hit “.” on my keyboard and Visual Studio tells me what my options are.  I can go back and figure out what the type is by just hovering over the var declaration in Visual Studio.

Without those abilities the var keyword would not be as good.  Without those capabilities you would have to go back to where the variable was declared and possibly trace up a method call to figure out the return type to know what type the var variable will be initialized to.

About the author

John Sonmez

John Sonmez is the founder of Simple Programmer and a life coach for software developers. He is the best selling author of the book "Soft Skills: The Software Developer's Life Manual."