To var
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
varkeyword 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 thevarkeyword 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?