tags:

views:

338

answers:

5

I find the var keyword greatly helps in reducing noise in my C# code, with little loss of readability; I'd say that I now use explicit typing only when the compiler forces me to.

I know that using var does not change the runtime characteristics of my code. But the question has just occurred to me: am I paying a big penalty at compile time for all the extra work that the compiler is now doing on my behalf?

Has anybody done any benchmarks to see how much difference extensive use of var makes to compilation times?

+15  A: 

The types need to be checked anyway, this may even save time... ok, unlikely :)
You shouldn't care though - if your development environment is slow, buy more memory or a new computer. Don't change the way you write code.

Kobi
+1 ... and compiling C# is blazing fast if you compare to other languages like C or C++
David Rodríguez - dribeas
I appreciate the point: I'm not going to change my programming practice because of this - but I would like some specifics on the difference it makes.
Samuel Jack
Do you realize how many different things the compiler does for you already? `var` is just another tiny task...
Kobi
+1 for "may even save time". There is no reason to assume that type inference costs time; in fact, it should be 1.271 femtoseconds faster to just _use_ the type on the right side than to check if that type is assignable to the left side.
ammoQ
Plus parsing the token `var` from text will be faster than parsing the token `IDictionary<int, IEnumerable<IFish>>`, saving yet another 0.431 femtoseconds.
Mark Byers
+3  A: 

The correct answer is "nothing measurable". For a partial (yet LONG) list of the passes the C# compiler makes while compiling, look here:

http://blogs.msdn.com/ericlippert/archive/2010/02/04/how-many-passes.aspx

Then understand that the type inference is only part of a single pass on that list.

Addys
+9  A: 

My advice: try it both ways. Measure the results. Then you'll know.

I haven't done any benchmarks, and even if I had, that wouldn't answer the question for you. We do not know what hardware you have, what else is running on your machine, what a typical program looks like. Nor do we know what you consider to be acceptable or unacceptable performance. You're the only one who knows all that, so you're the only one who can answer this question.

Eric Lippert
+1  A: 

The type of the right hand side needs to be found anyway to do type checking and/or type conversion. Assigning the result to the variable's type is cheap. Most of the cost (if any) will be in what had to be done to allow the expression to be evaluated before all the local variables were declared but you pay for this even if you don't use var. (BTW, it's possible or even likely that the above constraint doesn't hurt performance at all.)

BCS
A: 

The only issue I've seen with var is the loss of type safety. I only use them for Linq queries where you're getting anonymous types back. For general usage, though, it's discouraged.

The hard-liners are worried that var is pushing C# back to VB6 days of implicit typing...

edit: You're right--I skimmed too quickly. So I guess there's no problem with it as long as you're using it correctly.

andrew
-1: there is no loss of type safety. What are you talking about? It's strong typing - as strong as before `var`. It's just that the compiler infers the type. This has nothing to do with Variants in VB6.
John Saunders
You have confused implicit typing with dynamic typing; they are orthogonal. As of C# 4, we have all four: explicit static typing, explicit dynamic typing, implicit static typing and implicit dynamic typing. I recommend against that last one.
Eric Lippert