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#?
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.
var with LINQ statements is a bad idea because "it's not clear what the type of id is". –
Mouth var id = GetId();. If I assume GetId returns int, and type it int id = GetId(); now I have a compilation error if GetId returns a GUID. I still have to look it up. –
Cullan var on ambiguous declarations is also a great pain in pull request reviews in web UIs like bitbucket or github. You can't hover the declaration to get the type. Personally I have a very strict policy about it: use var only when using new on the other side of the operation (this includes anonymous types) or when using explicit casting (although I tend to not use var here as well). –
Egin 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?
var q = GetQValue(); is not a bad thing. It is, in fact, the C# coding standard recommendation to do so. The type of q would be inferred instantly from the return type of that method. Simple :) –
Attributive In most cases when used 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:
In these cases, you can get into trouble with any type resolution - for example:
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
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.
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..."
You may consider Microsoft's opinion to be relevant, since C# is their language:
"However, the use of var does have at least the potential to make your code more difficult to understand for other developers. For that reason, the C# documentation generally uses var only when it is required."
See MSDN - Implicitly Typed Local Variables (C# Programming Guide), last paragraph.
You should also be aware that var removes the compile-time datatype test on the initial assignment.
var x = "mistake"; // error not found by compiler
int x = "mistake"; // error found
Since most variables are only assigned once, consistent use of var removes almost all datatype tests on variable assignments.
This makes your code vulnerable to accidental changes e.g. those made by merge tools or tired developers.
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
http://blogs.msdn.com/jaredpar/archive/2008/09/09/when-to-use-type-inference.aspx
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.
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.
Understanding 'var' in Plain English
I'm going to show you that using AND not using 'var' is about communicating clearly.
I'm going to show examples of cases where using 'var' makes the code easier to read, and other examples when using var makes things hard to understand.
More than that you'll see that how clear 'var' is depends a lot on what you name everything else in your code.
Take this example:
Jake said hello to Bill. He didn't like him so he turned and went the other way.
Who went the other way? Jake or Bill? In this case "Jake" and "Bill" are like the type name. And "He" and "him" are like the var keyword. In this case it might help to be more specific. The following for example is much clearer.
Jake said hello to Bill. Jake didn't like Bill so he turned and went the other way.
In this case being more specific made the sentence clearer. But that's not always going to be case. In some cases being specific makes it harder to read.
Bill likes books, so Bill went to the library and Bill took out a book that Bill has always liked.
In this case it would be easier to read the sentence if we used "he" and in some cases left out his name all together, this is the equivalent of using the var keyword.
Bill likes books, so he went to the library and took out a book that he has always liked.
Those analogies cover the gist, but they don't tell the whole story. See in those examples there was only one way to refer to the person. Either with their name, for example Bill, or by a more general way, like "he" and "him". But we're only working with one word.
In the case of the code you have two "words", the type and the variable name.
Person p = GetPerson();
The question now becomes is there enough information there for you to easily determine what p is? Would you still know what people is in this scenario:
var p = GetPerson();
How about this one:
var p = Get();
How about this one:
var person = Get();
Or this one:
var t = GetPerson();
Or this one:
var u = Person.Get();
Whether the keyword var works in a given scenario depends a lot on the context of the code, like what the names of the variables, classes, and methods are, as well as the complexity of the code.
Personally I like to use the var keyword it's more comprehensive to me. But I also tend to name my variables after the type so I'm not really losing any information.
That said sometimes I make exceptions, such is the nature of anything complex, and software is nothing if not complicated.
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.
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.
From Department of Declaration Redundancy Department (from Jeff's Coding Horror):
"I use implicit variable typing whenever and wherever it makes my code more concise. Anything that removes redundancy from our code should be aggressively pursued -- up to and including switching languages."
I myself think it is worth taking about, but creating a comprehensive guideline on when to use or not would be overkill.
as of c# 9.0 we don't really need var.
we can simply
Dictionary<string, List<int>> field = new();
explicit type and short init.
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.
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.
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.
IEnumerable rather than IEnumerable<DataRow>. When you specify the type in the foreach loop, the C# compiler silently puts a cast in there for you. This isn't an issue with var, you were just a victim of an old API that was never updated for Generics. Try doing a foreach/var loop over table.Rows.Cast<DataRow>() sometime and you'll see the difference. –
Squamation 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();
obj.Start();
var test = "Test";
test.GetType();
obj.Stop();
lblResults.Text = obj.Elapsed.ToString();
}
private void btnString_Click(object sender, EventArgs e)
{
Stopwatch obj = new Stopwatch();
obj.Start();
string test = "Test";
obj.Stop();
lblResults.Text = obj.Elapsed.ToString();
}
First Label result is: 00:00:00 000034
Second Label result is: 00:00:00 00008
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. –
Rajah test.GetType(); on the first but not the second function? This difference makes the results incomparable. –
Snatch © 2022 - 2024 — McMap. All rights reserved.
varis there for good reason. And it's perfectly obvious what the type is even without hovering over it.var x = new Customer();It's a Customer object. Simple :) – Attributivevar foo = bar.Coords;? What isCoords? An array of floats? Ints? A different object entirely? If you have to rely on your IDE to provide that clarity, then there is something seriously wrong with your coding standards. And god help any new programmers you bring into the fold. – Actinomorphicvarwas introduced to support anonymous types which (I may be wrong) I believe was largely to support LINQ. So it should be limited to these usages IMO for all the readability reasons stated here. C# is a strongly typed language and should be written to look like it when possible ... again IMO. – Prejudgevar. I tend to write my code so that it's declarative and readable, so I never have any issue with a liberal use ofvar. Swings and roundabouts, I guess :) – Attributive