Joshua Flanagan

As I stated in my last post, the var keyword is an acknowledgement that I do not care what the type of the variable is - I only care what it can do.

Into the IUknown

Most developer start on the path to this revelation when they discover interface-based programming.

Consider: we need to write a method that returns a collection of strings. Callers of the method will only need to loop over the items and perform some action. The number of elements to return is not known at compile time, so we'll declare a generic List<string>, populate it within a loop, and then return it to the caller.

The junior developer will declare the return type of the method as List<string>:

List<string> GetNames(){}

Acknowledging that callers should not be bothered with having to know an implementation detail (the fact that a List was used instead of a fixed-sized array), and knowing that they only need to loop over the returned items, a more experienced developer might declare the method:

IEnumerable<string> GetNames() {}

Which means any variable the receives the return value will also be typed as IEnumerable<string>:

IEnumerable<string> names = GetNames();

Here's the kicker - in both scenarios, the GetNames method is really returning an object of type List<string>! When the supposedly more experienced developer chooses to return a more abstract type like IEnumerable<string>, type information is lost. Yikes! The names local variable above holds a List<string> instance, but you (the client developer) don't know it. As scary as that might sound, you probably realize that you don't care. As long as you can do the things you need to do with names (loop over it), you are happy.

Walking like a duck

Now let's take that train of thought and consider duck typing in a dynamic language like Python. I can declare the following method:

def Recycle(service):
    service.Stop()
    service.Start()

It takes a single parameter named service. What is the type of the parameter that is expected? I don't know. And after the initial anxiety settles, there is the liberating realization that I don't have to care! All I know, or care, is that any object instance that is passed to this method must implement a Start() and a Stop() method. The same method can be used with instances of a Lawnmower, AuditLogger, or SongPlayer class (assuming they all have Start and Stop methods).

Getting closer to the goal

Let me be clear - I am not suggesting that implicit typing in C# 3.0 is the same as duck typing. What I am suggesting is that the 2 examples above are points along the "progression of understanding" of the same concept: it is the behavior of an object that really matters, as opposed to the type name that is attached to it. Interface-based programming is near the start. Implicit typing is further along the progression. Duck typing is closer to the end.

I think we will find that programmers who have been exposed to and understand languages which support duck typing will be more likely to be comfortable with and embrace the var keyword. They have already made the mental leap that type information serves the computer more than it serves the human. If you haven't yet, do yourself a favor and learn a dynamic programming language, even if you know you will continue to spend your days with static typing.

Dare Obsanjo asked the question To var or not to var? He asserted "case closed" at the end of his post, and closed it to further comments, but I would like to continue the conversation.

He pulls out the common straw man argument that the anti-var (C# 3.0's implicity type keyword) crowd likes to attack. They assume that fans of implicit typing just want to save a few keystrokes. It isn't about less keystrokes. For me, its about thinking a little bit less like a computer and a little bit more like a human. I prefer to think less about Types and more about behaviors. The var keyword is an acknowledgement that I do not care what the type of the variable is - I only care what it can do.

I'll address a few specific quotes from his post (emphasis is mine).

[Referring to ReSharper] So it seems there are two suggestion modes. The first suggests using the var keyword when the name of the type is obvious from the right hand side expression being evaluated such as casts or new object creation. The second mode suggests replacing type declarations with the var keyword anywhere the compiler can infer the type... The first suggestion mode makes sense to me since the code doesn't lose any clarity and it makes for shorter code. The second mode is the one I find problematic it takes information out of the equation to save a couple of characters per line of code.

In both situations, it is about removing compiler noise. I have already given the compiler enough information for it to do its job. I don't care about a couple characters.

For example, the claim that it leads to "better naming for local variables" really means it compels developers to use LONGER HUNGARIAN STYLE VARIABLE NAMES.

Longer, more descriptive variable names? Yes, please. Hungarian style? That assumes I care about the type (which I don't see my follow-up post).

...these long variable names add more noise to the code overall since they show up everywhere the variable is used compared to a single type name showing up when the variable is declared.

This is completely different understanding of the term "noise" as it relates to code. To me, "noise" in a computer language is all of the stuff that makes code look like something that needs to be decoded. It is all of the stuff that normal humans would not use when communicating with each other. Your source code is a communication medium - it communicates intent to the computer, and to the humans that need to maintain it. Anything that is added purely for the computer's benefit is noise to the human. It commonly takes the form of angle brackets, parentheses, semi-colons, etc. Sometimes it takes the form of redundant or extraneous type information. But I would never consider a descriptive variable name "noise", just because it takes up a little more screen real-estate.

It is interesting that Dare seems to reject the argument that var helps promote use of better variable names, and yet the example which spurred his post illustrates it perfectly:

I found this change to be somewhat puzzling since while it may have shortened the code by a couple of characters [There he goes counting characters again] on each line but at the cost of making the code less readable. For example, I can't tell what the type of the variable named lvi is just by looking at the code.

The var keyword did not make the code less readable, it just made the poor choice of variable names more apparent. Might listItem or feedItem be a little more readable than lvi?

It seems his primary argument against var is that always knowing the type of a variable is of utmost importance. Why? When you are writing code, doesn't your IDE let you know what behaviors are available to your object instances? When you are reading code, can you not assume that the compiler has already checked it for invalid code?