When a programming language introduces a new language feature, inevitably that feature will become central to a style debate; When to use it, when not to use it, good places to use it, bad places to use it; places where it makes code easy to read, places where it makes code hard to read, and so on. the var Keyword is definitely no exception.

So What Is it?

“well, I’ve never seen one before, no-one has, but I’m guessing it’s a White Hole” – Kryten

The var keyword was introduced in C# 3.0. It allows for what is known as implicit typing– this allows a type to be inferred from the context by the compiler. var something=expression results in the something type being defined based on the type of the result for expression.

One thing to not confuse var with is Dynamic Typing where the type of a variable can change as the program runs- a variable with a string in python could be storing a number later or even a class instance. the use of inferred typing doesn’t change the conventional rules, and the code compiles to the same code it would if the type was fully defined, so it’s nothing more than a syntax sugar that can be used to shorten longer code.

The debates regarding var typically center around arguments that, when misused, it can make code harder to read. Personally, I am of the mind that in the situations where it makes code harder to read, it is not var that is pathological, but rather it is exposing a symptom of another problem.

A common-ground is found amongst most "factions" of the debate in terms of simple variable declarations which initialize to a new instance:

can be replaced with:

It is where we come into many other cases that opinions tend to differ for example this:

This tends to be the sort of example of "bad code"- here, we don’t know what type "value" is without hovering over it. We might assume it is a Something class, for example, but it may not be.

This is where I disagree. The problem I’ve found is examples tend to be precisely like that- simple, one-line pieces of code demonstrating the "folly" of using var. But outside of code obfuscation contests, I don’t think there are examples of real-world programs that are only one line, and certainly not so short of one. Code lines exist with other code above and below them- they exist within a specific context- not just the surrounding code, but the containing class, the containing namespace- even the general design of the project as a whole, which can inform a reader of this information that people often argue is no longer present when using var- to say nothing of a meaningful variable name, which is often not present either.

As a specific example, let me rip out a var line from an existing project:

This would seem a prime example of var being misused. What is "ghosted"? Is it a "GhostDrop" class? or what? Well, as it happens, it is a Nomino. This would seem to be a counter-example. However, as I mentioned, the context in which the code exists informs readers familiar with the project – BASeTris, in this example- GhostDrop being the logic that duplicates and translates an active Nomino Group into another Nomino group to be the “Ghost Drop”.

Another consideration is that for all the claims of it being hard to read:

because you do not know the type of “foo”, it seems the same contrived argument could be made against the use of fields:

And properties:

and out variables:

Which is obviously not something that tends to follow from claims that var makes code more difficult to read. In my opinion, var is not different from those two examples. If code is not written in an informing way, you will need to look elsewhere. However if the code is written well, in the context of the project and the person reading it has some basic understanding of some of the core classes, types, and conventions of a project, than it doesn’t usually get in the way. It could cause trouble if a project is unfocused, has several classes that perform similar “verbs”, or simply has less-than-perfect variable, function, property, and class names.