Sean's Blog

My Development Blog

  Home  |   Contact  |   Syndication    |   Login
  17 Posts | 0 Stories | 96 Comments | 0 Trackbacks



.NET Development

C# 3.0 brought with it a plethora of great additions, such as LINQ, lambda expressions and anonymous types. With the inclusion of LINQ, Microsoft decided that it was often difficult to determine the return type from a LINQ expressions. As such, they opted to include the var keyword, which is used to implicitly define a type. The type is determined by the compiler at compile time, making it strongly typed, so it is not analogous to the Visual Basic variant type. While this has some value in aiding in building LINQ expressions, I often find the use of the var keyword to be unclear (in my opinion) when used to define variables. In C# 3.0, for example, the following code is completely legit:

static void Main()
    var myInt = 10;

The code above defines an integer named myInt. While this particular example may be clear, I have found other situations where the use of the var keyword has made code less readable.

static void Main()
    var myEmployee = new Employee();

Still not terribly unclear because the type is on the same line. But we’re starting to get unclear because my eyes start at the left to determine the type. But what if the type isn’t on the same line? What if it’s the return value of some method in another class?

static void Main()
    var myEmployee = new Employee();
    var i = myEmployee.GetSomething(); // Unclear

What does the type above return? We could argue that the name GetSomethig() isn’t explicit enough. That’s a valid argument, but are all methods inherently named explicitly enough to determine the type returned? Absolutely not. As a result, I find myself having to reach for the mouse to hover over the the method to see a tooltip that I can use to make that determination. It slows me down. Is it that difficult to explicitly declare the type of your variable ahead of time? It makes maintenance and readability a lot easier.

posted on Saturday, July 25, 2009 9:17 AM


# re: Unclear Use of C# var Keyword 7/25/2009 11:26 AM Steve Horn
If the method/property name on the object is not clear (GetSomething()) then it's your opportunity as the consumer/user of the class to come up with a better name and refactor accordingly.

Further, even if the variable 'i' was explicitly typed I'm still left guessing as to what state that variable is in based on the poor naming of the "GetSomething()" method. This makes it likely that you're going to have to inspect the inner workings of that method anyway.

Just a thought.

# re: Unclear Use of C# var Keyword 7/25/2009 11:46 AM Sean

That's a completely valid argument. I arguably have equal concern with proper naming of variables. That, however, is a side topic, in my opinion. When I'm the original author of the consumer, I should name my variables appropriately. It doesn't, however, mean that other developers will declare their variables with names that will explicitly define their intended purpose.

We could certainly refactor the consuming code and give the variable a more meaningful name (the Visual Studio rename function has made this a breeze). I still find, however, that making the type known makes the code more readable.

Thank you for the feedback.

# re: Unclear Use of C# var Keyword 7/25/2009 1:15 PM Samer Paul
When I first started working with LINQ, I pretty much exclusively used var because, well, the book I worked from used it everywhere.

But as you suggest, as time went on, it was pretty clear it made more sense to go ahead and figure out exactly what you were returning, so that there is no confusion.

It actually ended up making my queries a lot cleaner, and more thought out, because I had to know from the beginning what I wanted to end up with.

# re: Unclear Use of C# var Keyword 7/25/2009 4:35 PM Markus Olsson
I like you reasoning here. The policy which we have adopted at work is that it is okay to use var only when the type is clear, ie your second example.

var employee = new Employee(); // Okay
var employee = EmployeeProvider.GetEmployee(1) // Not okay

# re: Unclear Use of C# var Keyword 8/1/2009 9:41 AM Adnan Ahmad
Check out my posting about Vars. I am all for explicit programming!

# re: Unclear Use of C# var Keyword 8/2/2009 4:45 AM Uri
Feel the same, please see:

# re: Unclear Use of C# var Keyword 8/4/2009 12:35 PM Jon Arild Tørresdal
I'm all for var! I like it. Though if for some reason you cannot tell what type it is by the name of the variable or the method, I opt it out. I can probably count the number of times I've done that on one hand though. I find it extremely important to give good name to variables, methods, classes etc. This will usually result in this not being a problem.

# re: Unclear Use of C# var Keyword 8/4/2009 12:49 PM Sean

While you may not mind it, there are many that do. My argument is more that using var makes the code less readable. Explicitly acknowledging the type at the time of declaration does not make the code less readable.

Thank you for your comment,


# re: Unclear Use of C# var Keyword 8/24/2009 3:47 PM Tim
Marcus, is it really that much harder to use the standard explicit typing?

Employee employee = new Employee();
Employee employee = EmployeeProvider.GetEmployee(1);

From what I see, your usage of "var" is just "Golden Hammer" syndrome.

# re: Unclear Use of C# var Keyword 9/18/2009 4:14 AM hfrmobile
I absolutely agree with Sean.
Thanks for putting your concerns to the public.

# re: Unclear Use of C# var Keyword 2/26/2010 3:18 AM Mani
I also like var; It has few benefits,
1. As a developer I don’t care about DATATYPE declaration while assign the values from other functions/properties.
2. I don’t need to use Import/Using statement on top of my class, no conflict namespaces/class declaration;

# re: Unclear Use of C# var Keyword 6/6/2010 5:52 AM Mohamed Radwan
I agree with you but did any one know why Resharper has suggestion to transfer your explicit type to implicit using var?

Post A Comment