Why would var be a bad thing?

Question

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

Answer 1

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..."

Answer 2

Eric Lippert sums it up well:

• Use var when you have to; when you are using anonymous types.
• Use var when the type of the declaration is obvious from the initializer, especially if it is an object creation. This eliminates redundancy.
• Consider using var if the code emphasizes the semantic "business purpose" of the variable and downplays the "mechanical" details of its storage.
• Use explicit types if doing so is necessary for the code to be correctly understood and maintained.
• Use descriptive variable names regardless of whether you use "var". Variable names should represent the semantics of the variable, not details of its storage; "decimalRate" is bad; "interestRate" is good.

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.

Answer 3

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.

Examples:

Implicit conversion:

static void Main() {
    long x = 17;
    Foo(x);
    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();
    x.Go();
    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(); }
}

etc

Answer 4

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.

Answer 5

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.