Var: Possibly the most contraversial language feature ever?

Posted on Updated on

I’ve been prompted to write this post after it cropped up in my office recently, and I was reminded of a job interview I had a couple of years ago. I’ve also seen some discussions online, and wow, some people hate var. I mean really, really hate it. I even saw one guy in a post saying that if he saw a job applicant using var in an interview he would instantly refuse to hire the guy.

Now, I understand the points that the opponents of var are making, but I don’t agree. I accept that in the case of:

var data = GetData();

we can’t tell what type “data” is, but this is one of the few examples where this is the case. You might also argue that the method “GetData” has been atrociously named (okay, no arguing, it has been atrociously named), but following most programming rules I’d expect that method to return an object of type “Data”. In this example that’s probably not the case, but it does highlight my point, that this:

var customer = order.GetCustomer();

is valid use of var. I can clearly see that the expression on the right hand side will return an object of type Customer. Any time the type of the expression on the RHS is obvious (such as when the RHS is a literal, constructor call or enum member), I would say that it’s fine to use var. This includes the following examples:

var orderCount = 0; // I am a C# developer. I know that "0" is 
                    // an Integer literal. If it was a decimal I would see "0m".

var welcomeMessage = "Hello world"; // Same goes for string literals

var openForWriting = true; // Even for booleans too

var people = new List<Person>(); // Adding List<Person> to the LHS of this
                                 // statement would add no value whatsoever

var backgroundColor = Colors.Blue; // Again, the type of the variable is 
                                   // clearly visible, it's just on the RHS of the statement

Obviously, this whole discussion is moot in cases where you either must use var (in the case of anonymous types) or cannot use var (when you want to specify that the variable has a type higher in the heirachy than the RHS, such as Fruit myLunch = new Orange();)

Here is what Eric Lippert has to say on the issue: http://blogs.msdn.com/b/ericlippert/archive/2011/04/20/uses-and-misuses-of-implicit-typing.aspx

Opponents of var say that it’s an awful language feature that should never have been added – that regular use of var is “abuse” of a language feature. This position seems ridiculous to anyone who’s done any amount of functional programming. Take the following function definition in F#:

let add x y = x + y

Is the example above unreadable? It has no type annotations whatsoever; in C-based languages we would expect to have to state the types of parameters x and y, as well as the return type of the method. For reference, the equivalent C# would be (albeit writing a method rather than a local function):

public int Add(int x, int y)
{
    return x + y;
}

Perhaps it’s not obvious to someone who’s never written any F# before, but it only takes a few minutes to learn that the F# compiles assumes that variables are ints if you use mathematical operators on them: in this case a plus (+). So in F# we have not only type inference from the declaration of a variable but from its usage as well.

It doesn’t take long to get used to this as a concept. In fact, writing some programs in F# will convince you that unnecessary type annotations are simply noise in your program.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s