-1

I really confused about usage var keyword in C#.
I know, that var make code more easier to read, but what about speed and memory?

A.

  1. var a = 100;
  2. int b = 100;
  3. int c; c = 100;

B.

  1. var listA = new List<obj>();
  2. List<obj>listB = new List<obj>();
  3. List<obj>listC; listC = new List<obj>();

Which faster?
There is a dependence on the type?
How much memory is allocated in both situation and when that memory allocated?

jimpanzer
  • 3,470
  • 4
  • 44
  • 84
  • 2
    I would argue that var makes code harder to read, as with php, you're not always sure what type a var is, especially if it's heavily nested, or hidden in an API for example. – Kestami Apr 25 '13 at 14:59
  • 1
    _Which is faster?_ http://ericlippert.com/2012/12/17/performance-rant/ – Soner Gönül Apr 25 '13 at 14:59
  • @Shane.C I would rephrase "var makes possible to make code more easier to read *sometimes*". – Andrey Apr 25 '13 at 15:00
  • @Andrey perhaps you're right..i guess it's just opinion! : ) – Kestami Apr 25 '13 at 15:00
  • @Shane.C That's why it should be used selectively, for instance, with statements such as `var thing = new Thing();` and _not_ with `var thing = something.GetUnknownThing();`. Humans make code easier to read. – Grant Thomas Apr 25 '13 at 15:02

6 Answers6

5

Which faster?

Neither, they're the same.

There is a dependence on the type?

I'm not sure what you're asking here, but there's no difference between any of those code snippets once they are compiled, so I'll go with no.

How much memory is allocated in both situation and when that memory allocated?

It's the same for all of them. For the int example it's 32 bits for all cases. For the List example all three will allocate one word for the reference, plus the memory for the actual list instance.

Servy
  • 202,030
  • 26
  • 332
  • 449
2

It is purely compilation step feature. Compiler infers the type of the expression on the left, and uses it as variable type. So resulting IL will be the same.

So:

var list1 = new List<int>();
List<int> list2 = new List<int>();

Are completely identical. But I can see some examples where specifying type can have some effects, like:

var i1 = 5;
int i2 = 5;
//vs:
var i2 = 5;
object i2 = 5;

So if actual expression type is exactly the same as declared variable type then they are completely identical. But var can be different if expression type and variable types are not the same.

Andrey
  • 59,039
  • 12
  • 119
  • 163
  • +1 for explaining why there is no difference in the first case instead of just saying they are identical. – David S. Apr 25 '13 at 15:04
1

var keyword is just a syntactical sugar.

It is not present in the IL, so there's no difference.

Duplicate topics:

Is there a performance hit in using the 'var' keyword in C#?

Will using 'var' affect performance?

Community
  • 1
  • 1
Artur Udod
  • 4,465
  • 1
  • 29
  • 58
1

When to use var and where not to use. (Because all other questions are answered here already) Why var?? - Anonymous types and LINQ

Anonymous (temporary use) types:

var v = new { Amount = 108, Message = "Hello" };

General:

Use:

var myList = new List<string>();

Here it is obvious what type myList has - code reading is good

Don't use:

var properties = myPropertyHandler.GetProperties();

Here you have no idea what type returned by GetProperties - code reading is bad. Declare:

AppProperties properties =  myPropertyHandler.GetProperties();
T.S.
  • 18,195
  • 11
  • 58
  • 78
0

Var keyword works only then C# compiler generates assembly's IL code, the type of variable to create is calculated by the right side of expression (which must be specified and cannot be null). Var does not affects anything in runtime.

Loryan55
  • 325
  • 4
  • 13
0

var is inferred from whatever is returned from the statement on the right. This is done by the compiler, so when the program is actually run, there is no difference.

Watch out, however, that you will not get a compiler error if the statement produces an unintended type.

David S.
  • 5,965
  • 2
  • 40
  • 77
  • 1
    The most common way that unexpected type inference will cause a problem in otherwise-reasonable code is by preventing compilation of downstream code that tries to rewrite the variable with a less-specific type than had been inferred. Otherwise, with one exception, reasonably-written code which uses type inference will either work or fail at compile time. The biggest "gotcha" is probably with `GetEnumerable` methods that return value types. `var en = MyList.GetEnumerator()` may behave differently from `IEnumerable en = MyList.GetEnumerator()` even if both compile. – supercat Apr 25 '13 at 15:53