Take the 2-minute tour ×

I've been chatting with my colleagues the other day and heard that their coding standard explicitly forbids them to use the var keyword in C#. They had no idea why it was so and I've always found implicit declaration to be incredibly useful when coding. I've never had any problems finding out what type the variable was (you only hover over the variable in VS and you'll get the type that way).

Does anyone know why it would be a bad idea to use the var keyword in C#?

share|improve this question
I wonder if this decision was a majority/consensual decision of the development team or if it was single handedly declared by some manager. –  Tamas Czinege Feb 13 '09 at 11:54
@DrJokepu: I didn't ask since we switched subject to LINQ goodies. But I wouldn't be surprised if it was declared by a manager of sorts. –  Spoike Feb 13 '09 at 11:58
You should feel lucky for not having to work with code standard like here: thedailywtf.com/Articles/Astigmatism.aspx –  Codism May 20 '10 at 16:54
add comment

17 Answers

up vote 30 down vote accepted

The writers of the .Net Framework Design Guidelines (awesome book) that came out in November 2008 recommend considering using var when the Type is obvious and unambiguous.

On the other hand, if using var would result in an ambiguity when reading the code, as Anton Gogolev pointed out, then it's better not to use it.

in the book (Annex A), they actually give this example:

var names = new List<string>(); // good usage of var

string source = GetSource();
var tokens = source.Split(' '); // ok; most developers know String.Split

var id = GetId(); // Probably not good; it's not clear what the type of id is

It's possible that, to ensure that readability is not subjected to the whims of lowly developers, your organisation has decided that you were not worthy of var and banned it.
It's a shame though, it's like having a nice tool at your disposal but keeping it in a locked glass cabinet.

In most cases, using var for simple types actually helps readability and we must not forget that there is also no performance penalty for using var.

share|improve this answer
The big think I think everyone misses in this war is "hover over the variable" I can't see what GetId() returns here, but how often do you read complicated code that isn't in your IDE? Tooling is an important part of the language. –  John Oxley Sep 8 '09 at 16:50
why hover over every variable when you could just read it without the extra work? wtf –  alchemical Feb 5 '10 at 22:39
@alchemical: well what does GetId() return without looking up the interface or hoover over the item? –  RvdK May 20 '10 at 13:09
@PoweRoy: I think that was his point - it's always obvious when explicity typed.. long id = GetId(); –  DefenestrationDay Jun 15 '11 at 12:17
add comment
var q = GetQValue();

is indeed a bad thing. However,

var persistenceManager = ServiceLocator.Resolve<IPersistenceManager>();

is perfectly fine to me.

The bottomline is: use descriptive identifier names and you'll get along just fine.

As a sidenote: I wonder how do they deal with anonymous types when not allowed to use var keyword. Or they don't use them altogether?

share|improve this answer
My current job maintains a code base built from .NET 1.1. While modified now to work under 3.5, the majority of the code uses 1.1 principals. I would imagine a lot of developers are in the same boat and don't use anonymous types out of habit. –  Greg May 20 '10 at 13:11
@Greg We're not talking anonymous types here. –  Anton Gogolev May 20 '10 at 13:24
you asked a question in your answer about anonymous types.... –  Greg May 20 '10 at 13:42
+1 for your good example. –  rockXrock Mar 18 '13 at 9:22
add comment

Surely this is a mistake. It's because some folk don't realise that it is actually strongly typed, and not at all like a var in VB.

Not all corporate coding standards make sense, I once worked for a company who wanted to prefix all class names with the company name. There was a massive rework when the company changed it's name.

share|improve this answer
You mean a Variant, not var :) –  dreamlax Feb 13 '09 at 11:33
You should be ashamed to admit that you remember! ;-) –  NeedHack Feb 13 '09 at 11:40
Ouch! @ Prefixing classnames with the company name. –  Spoike Feb 13 '09 at 11:46
LOL, have this problem right now. this is so good when you have Refactoring. –  Avram Feb 13 '09 at 12:14
I went through the same thing, renaming all the functions when the company decided it wanted to use a different prefix. –  MrZebra Feb 13 '09 at 12:22
show 5 more comments

In most cases when uses sensibly (i.e. a simple type initializer where the type and value are the same), then it is fine.

There are some times when it is unclear that you've broken things by changing it - mainly, when the initialized type and the (original) variable type are not the same, because:

  • the variable was originally the base-class
  • the variable was originally an interface
  • the variable was originally another type with an implicit conversion operator

In these cases, you can get into trouble with any type resolution - for example:

  • methods that have different overloads for the two competing types
  • extension methods that are defined differently for the two competing types
  • members that have been re-declared (hidden) on one of the types
  • generic type inference will work differently
  • operator resolution will work differently

In such cases, you change the meaning of the code, and execute something different. This is then a bad thing.


Implicit conversion:

static void Main() {
    long x = 17;
    var y = 17;
    Foo(y); // boom
static void Foo(long value)
{ Console.WriteLine(value); }
static void Foo(int value) {
throw new NotImplementedException(); }

Method hiding:

static void Main() {
    Foo x = new Bar();
    var y = new Bar();
    y.Go(); // boom
class Foo {
    public void Go() { Console.WriteLine("Hi"); }
class Bar : Foo {
    public new void Go() { throw new NotImplementedException(); }


share|improve this answer
nice examples, never thought of that –  RvdK May 20 '10 at 13:10
Another example: Changing "Car myCar = BuickFactory.MakeCar;" to "var myCar = BuickFactory.MakeCar;" may not change the code if BuickFactory.MakeCar returns Car, but if a later version of BuickFactory shadows MakeCar to return a Buick, the type of the myCar variable would get changed. If running code tries to assign some other type of Car into myCar, it will fail. –  supercat Jan 27 '11 at 22:23
add comment

I wrote a blog article on this topic a few months ago. For me, I use it every where possible and specifically design my APIs around type inference. The basic reasons I use type inference are

  1. It does not reduce type safety
  2. It will actually increase type safety in your code by alerting you to implicit casts. The best example in the foreach statement
  3. Maintains DRY principles in C#. This is specifically for the declaration case, why bother saying the name twice?
  4. In some cases it's flat out required. Example anonymous types
  5. Less typing with no loss of functionality.


share|improve this answer
add comment

var is the latest "how to lay out your braces"/hungarian notation/Camel casing debate. There is no right answer, but there are people who sit at the extremes.

Your friend is just unfortunate they work below one of the extremists.

share|improve this answer
add comment

Forbidding it entirely means forbidding the use of anonymous types (which become incredibly useful as you use LINQ more).

This is stupidity plain and simple unless someone can formalise a good reason to never use anonymous types.

share|improve this answer
add comment

It can hurt readability if it is misused. However completely forbidding it is a bit strange as your colleagues will have a tough time using anonymous types without it.

share|improve this answer
add comment

First, as a general rule, coding standards should be discussed and agreed by the team, and the reasoning behind them should be written down, so that anyone can know why they are there. They shouldn't be the Holy Truth from One Master.

Second, this rule is probably justified because code is more times read than written. var speeds up the writing, but may slow down the reading a bit. It's obviously not a code behaviour rule like "Always initialize variables" because the two alternatives (writing var and writing the type) have exactly the same behaviour. So it's not a critical rule. I wouldn't forbid var, I would just use "Prefer..."

share|improve this answer
add comment

This is really a readability issue with your code.

My personal preference is to only ever use "var" for anonymous types (indeed, if you wish to use anonymous types at all, you'll need to use var), and these mostly come from LINQ queries. In these cases, you have no choice but to use var if your query is projecting into a new (implicit & anonymous) type.

However, C# 3.0 will happily let you use var anywhere you like, outside of LINQ and anonymous types, for example:

var myint = 0;
var mystring = "";

is perfectly valid, and myint and mystring will be strongly-typed by the inferred values used to initialize them. (thus, myint is a System.Int32 and mystring is a System.String). Of course, it's fairly obvious when looking at the values used to initialize the variables what types they will be implicitly typed to, however, I think it's even better for code readability if the above were written as:

int myint = 0;
string mystring = "";

since you can see immediately at a glance exactly which type those variables are.

Consider this somewhat confusing scenario:

var aaa = 0;
double bbb = 0;

Perfectly valid code (if a little unconventional) but in the above, I know that bbb is a double, despite the initializing value appearing to be an int, but aaa will definitely not be a double, but rather an int.

share|improve this answer
To be honest, I find the example of object initialization equally readable both ways. For me declaration of the type when it's already apparent in plain sight is redundant visual noise. –  Spoike Feb 13 '09 at 12:30
Since there's no performance penalty to using var, it's quite a subjective thing. It can get more confusing if you initialize a variable with the return value of another function, though. (i.e var a = MyFunc();) since you now need to know what MyFunc returns in order to know what a is. –  CraigTP Feb 13 '09 at 13:00
add comment

Implicit typing is great, and people who flat-out prohibit it damage productivity and invite brittle code.

It's almost like type-safe, compiler-checked duck typing, which is incredibly useful when refactoring. For example, if I have a method which returns a List, and I refactor it to return IEnumerable, then any callers to that method which have used the var keyword and only use IEnumerable methods will be fine. If I've explicitly specified, e.g., List, then I've got to go and change that to IEnumerable everywhere.

Obviously, if any of the implicit-typing callers require List methods, then I'll get compile errors when I build, but if that's the case I probably shouldn't have been changing the return type anyway.

share|improve this answer
add comment

From Department of Declaration Redundancy Department (from Jeff's Coding Horror):


I myself think it is worth taking about, but creating a comprehensive guideline on when to use or not would be overkill.

share|improve this answer
add comment

I have had cases (when I foreach through a Table.Rows collection) when using var resulted in the type being of some base class rather than the actual DataRow type. That is the only time I have had trouble with var.

share|improve this answer
add comment

This link maybe useful.

share|improve this answer
add comment

Here are the results of a test I ran on efficiency of var versus explicit typing:

  private void btnVar_Click(object sender, EventArgs e)
        Stopwatch obj = new Stopwatch();
        var test = "Test";
        lblResults.Text = obj.Elapsed.ToString();

    private void btnString_Click(object sender, EventArgs e)
        Stopwatch obj = new Stopwatch();
        string test = "Test";
        lblResults.Text = obj.Elapsed.ToString();


First Label result is: 00:00:00 000034

Second Label result is: 00:00:00 00008

share|improve this answer
You might want to add test.GetType(); to the second function. Secondly, click in both forward and reverse order to account for caching effects. Thirdly, perform the test multiple times and average. Without that, you will have a useless result. –  Sjoerd Aug 1 '12 at 23:08
Why are you doing test.GetType(); on the first but not the second function? This difference makes the results incomparable. –  Spoike Aug 2 '12 at 8:52
If you look up the MSIL, var is actually changed to STRING.. So the two functions should be the same. –  Max Sep 27 '12 at 12:26
add comment

Eric Lippert sums it up well:


My own opinion: I find it harder to read and a bit pointless with types such as int, string, bool or even a User. It's about readability after all (except where using it with LINQ), so when vars are splattered about it can be harder to read and defeating the purpose of the keyword that the language designers intended it for.

share|improve this answer
add comment

Here are the reasons from the horse's mouth (Resharper)

share|improve this answer
add comment

Your Answer


