“You might even say implicit variable typing is a gateway drug to more dynamically typed languages. And that’s a good thing.”
Like PHP ? 
What you forgot: In the line
BufferedReader br = new BufferedReader (new FileReader(name));
the BufferedReader left can be replaced by an Reader. This has even sense; sometimes you must both load ASCII/UTF files and binary files
(InputStreamReader). So br could be a general Reader variable.
This is important because IDE’s can point out flaws when you erronously try to access BufferedReader methods in br when br is actually a Reader. Tell how do you avoid to declare types if we have an OO system with inheritance and interfaces if you want to find out
declaration errors in compile time.
what about when you want to do this
1: StringBuilder sb
…
100: sb = new StringBuilder(…)
I think it depends on your background, I prefer knowing that my objects and variables are well declared and aren’t going to change type dynamically.
The addition of “auto” and “var” are welcome. For most of the code I write, I don’t need something more complicated. But the reason it took some time is probably that it wasn’t clear what they should do.
Consider the question of redundancy in variable declarations, sometimes they aren’t so redundant. Jeff’s example (“Who came up with this stuff?”):
BufferedReader br = new BufferedReader (new FileReader(name));
In Jeff’s code it’s “obvious” that the first BufferedReader is redundant. But what about The following case?
AbstractReader br = new BufferedReader (new FileReader(name));
You see, the language designer has to consider all cases, not just the one you are using. The person who “came up with this stuff” had to think long and hard about such cases. Apparently they thought that they couldn’t figure out what “var” should do, so for the first few versions of the language they opted not to rob the programmer of this flexibility, at the cost of being more verbose.
Language design is HARD.
What should the following C++ cases do (similar issues are certain to exist in .NET):
auto x = 4; // is x int? unsigned int?
auto y = -5; // well, y should be int, right?
auto z = ‘\0’; // hmmm, char? unsigned char?
auto w = 0; // int again I guess? what if I wanted a pointer?
I am sure that if we look at the standard we will find the answer, and it will be logical and “intuitive”. However it took a while to came up with a good answer, and while they’re doing that, I’d rather have my verbose code working.
That’s one of the reasons I hate Java.
Damn, made a comment about this over on RefactorMyCode before this appeared in my reader.
I’m going to disagree with you and agree with the c#3.0 language designers: http://msdn.microsoft.com/en-us/library/bb383973.aspx
“Overuse of var can make source code less readable for others. It is recommended to use var only when it is necessary, that is, when the variable will be used to store an anonymous type or a collection of anonymous types.”
Don’t you need “var” because you are initializing a new variable instead of assigning a value to an existing one? Of course the compiler could check that VB6-style 
@Niyaz PK
LOL, that was quite funny…
Always hated C# (and it’s brethren) just for that reason (Along with the redundant semicolons and ()s)…
VB9 ftw! (LINQ is tastier here too!)
This is actually the first time I have come to disagree with you. I agree with the many previous posters who mentioned about the ambiguity over class hierarchy. Ex: SuperClassOfClass c = new Class();
I am always a fan of explicit code because it tells me more about every created object saving the guesswork regardless of how much easier to type it is. On longer projects I can forget what lines of MY OWN code is for, let alone the code written by someone else.
Then again, I’m only a student still…
Declaring a type of the variable is IMHO always a good thing as it helps readability. In most cases the type declared is an interface (or should be). So what you are declaring is not the actual implementation you will be using but a constraint on what might be used.
Comon Jeff, learn some haskell, ml, lisp, then write articles about programming languages and compiler tricks.
I actually think that the ‘var’ addition is good. It removes redundancy, especially for object with long names.
The trick is that you cannot really avoid having two information. And that’s because of OO. the first is object definition, the second one object declaration.
Basically, all does ‘var’ when you declare an object is to say to the compiler that the definition class is the same that declaration class.
However, for simple types, I don’t agree…
var i = 1;
just feels wrong.
I agree with you ‘M’, I find cases such as the following to be very useful, especially for the maintainer,
AbstractReader br = new BufferedReader (new FileReader(name));
It tells you a little about the class heirarchy.
Moreover, the last example could be:
var n = new {1, 2, 3};
Because as with (var maxentries = 5) it can be inferred at compile time that the expression is an array of all integers.
I think that this redundancy comes from C++ and maybe other languages, where an initialization rvalue, as “new someClass()” is treated as any other expression, which in this particular case happens to yield a someClass object.
I find it odd that LINQ uses “let” for local bindings within an expression and not “var”.
Still, I’m very happy about having it in C#!
I totally agree, implied types is a huge improvement in C#3
Is this in response to your feedback on http://refactormycode.com/codes/333-sanitize-html ?
If so they’re wrong and you’re right - I would avoid using var for simple value types (I feel “int i = 5;” is perhaps clearer than “var i = 5;”, even though both compile to the same thing), but for various collections and lists where you already know what you’re dealing with they’re great.
I disagree with you on this. In this example:
BufferedReader br = new BufferedReader (new FileReader(name));
The first BufferedReader is needed to differentiate between that and this:
ParentClassOfBufferedReader br = new BufferedReader (new FileReader(name));
In any case, I think using “var” when the type if known is a lazy way to write code. It makes it harder to read 'cos now I’ve got to think about what type a variable is and what methods/properties it provides.
Finally, if you don’t like the verbosity of C#, why not switch to other less verbose languages? Why misuse a C# feature? And it is a misuse because it goes against the opinions of the language designers.
-
var url = “http://tinyurl.com/5pfvvy”;
-
var maxentries = 5;
-
var pi = 3.14159;
-
string or url? is it obvious? no.
Actually, it is obviously a string. If you wanted to make it a URL type, you would do something like this: var url = new URL(“http://tinyurl.com/5pfvvy”);
- int or long? is it obvious? no.
- float or double? is it obvious? no.
When should you care?
When you’re writing video drivers and wringing every last femtogram of performance out of the hardware, that’s when. But you’d be using C for that.
In other situations, it’s OK to use a language where you don’t have to micromanage numeric types.
Learning what types are assigned to immediate values hasn’t proven to be much of a problem for any of the popular dynamic languages.
I’m surprised at how many people independently bring up the argument by appeal to authority. What is written in the MSDN is often one person’s opinion. And seriously, the coding guidelines in the MSDN, offered without any justification whatsoever, are often just counterproductive.
Over on refactormycode.com someone asked “What’s the benefit of using “var” …?” Well, Jeff has given a good many. And no, less typing is not one of them, per se. Rather, it’s avoiding needless typing. Remember: The best code is no code at all.