Less code noise == better readability

Bellware and I were having this exact same discussion the other day. Our take was that the people worried that “var” will be a problem may just be a symptom of other code ills like bad naming or long methods.

Note: this is not meant to be an attack on the idea, just some questions…

Ok. Now this was considered totally evil in the VB days 10 years ago. Now it is more readable? Why? Just because the IDE can tell me the type? What if I am not working in the IDE but just doing a code inspection on paper?

There were a great deal of arguments against this ten years ago (I can dig them up if required)., So why is it oK now? What has changed in the way we do code inspections and design applications to make this acceptable?

@dcarver:

Which do you consider more readable:

var customerList = new List();

or

List customerList = new List();

Now tell me how #1 is less readable than #2. In fact, if you even try to say that #2 is better – smack yourself upside your head.

But as well, if you see this:
var i = 0;
Find the developer and smack them upside their head.

Case 3, where you will say you should have the type is when you have an object returning something else:

var mystuff = mycustomObject.ReturnSomething();

The problem here is in the ambiguity of the function name (ReturnSomething — which I would almost call descriptive compared to code I’ve seen in the wild), give your no indication as to what is being returned. Fix your function names.

@Chris

So your argument is var in the VB days was Ok if we just named the variables better and had a decent initialization syntax?

@dcarver
No attack felt here, I think you have some valid points
-We did it this way 10 years ago
-Readability
-What has changed in the way we do code in 10 years

1) A lot has changed in the past 10 years, not only in how we design applications, but how we interact in general. (In fact more so the last 10) As an example, to touch on one of your discussion points, I do less and less on paper anymore, e.g. buy things, books, mail, bills, code inspections. (theres no resharper or tests, how would I find which page the inheritor was on?)

2) As for readability, there has been a tremendous amount of knowledge gained by the community set forth in practices and patterns in the past 10 years. OO code in general is more standardized in its naming convention. Code Samples, Books, Conferences, Mentors etc. I know that var customerRepository is a customer repository, has methods like Find, Add, Save etc. var customerList as Chris mentioned, if that’s not readable… well Ill be more polite and just say you probably have a training issue on your hands

3) VB 10 years ago was a procedural language, and variants were late bound at runtime. (and horrible to read) Contrast with C# 3.5 we are talking about an OO/Functional(ish) language where the var type is inferred at compile time (could maybe argue this is even somewhat dynamic). To me “var” in C# has some similarities to “let” in F#. I can initialize a local variable, and control the type I want to work with by chaining functions/expressions together. This doesn’t even begin to touch on anonymous types, linq etc.

let x = 42;;
val x : int

var customers = CustomerService.GetCustomers();
customers
.Convert(ToModel)
.OrderBy(c => c.Name)
.ToList()
.ForEach(SomeCustomerAction)

To me, Its not an apples to apples comparison, maybe like apples and…. Sushi? I think it is a natural evolution for C# (mixed with old ideas though), and one I would hate to slow by trying to let standards of the past impact it. Don’t get me wrong, I like my types, I just don’t care to explicitly declare at its initialization which part in its polymorphic grandeur I am working with, because it’s likely one of its many interfaces, or could be anonymous.

@Jeremy
Amen!