|
http://stackoverflow.com/questions/41479/use-of-var-keyword-in-c
Although I agree var can be abused, for the most part I have found that when used appropriately it adds value rather than subtracting it.
|
|
|
|
|
Again - read the post - I have no problem with var when it is used properly. The problem is that people don't use it properly, they use it everywhere.
|
|
|
|
|
I did read the post.
I then looked at the title "Var is Bad" and your following statments in the post:
"the bane of good programming – var"
"that doesn’t make it a good thing"
"Var is a crutch. It is there for lazy developers."
"Var is the same sort of thing – a feature that has very limited required usage, so let’s keep it that way and only use it when required, not all over the place."
You didn't really even say when you should use var in your article (in the strictest sense you would only need to use it for anonymous types). You mention one or two situations where you don't like to see it where it makes things confusing. I agree with that, I don't think it is ever a good idea to make code more confusing to read.
The last quotation I have above makes it sound like you want to only use var when strictly necessary (anonymous types).
I think that is a little too blunt, along with "var is Bad". It is a tool that can be used or abused, just like any other feature of the language. There are just as many examples when it has made my coding easier to read than it has complicated it. Yes, it requres a little thought about when it makes sense to use it or when it would be clearer to make the full declaration. But making blanket statements about var being bad seems too extreme.
|
|
|
|
|
Instead of saying, var is bad. Maybe something along the lines of "Some pro's and con's of using the var keyword". I think that this post should include some other examples besides that one. A great conversation of this is going on over at StackOverflow.
http://stackoverflow.com/questions/41479/use-of-var-keyword-in-c[^]
http://michaelcrump.net
|
|
|
|
|
|
I think most of us coding in C# also have intellesense. In your example, if I'd forgotten what type value1 is, I would hover over it and see. Or is intellesense bad too because it's a crutch? I disagree with your use of "bad" and "crutch" which means I pretty much have to disagree with most if not all of this post.
|
|
|
|
|
So how is that intellisense useful to you when you are doing a code review on some below average programmer's code, since you likely aren't doing a code review in Visual Studio? Like I said, the poor programmers in the world are the likely culprits of overusing var (since a the group of poor programmers overlaps the group of lazy programmers quite a bit), and if you have to review their code, you're going to want to know what those variables are without having to scan through a ton of code to find where it was created, and then potentially through tons more code just to find the function that is doing the creation to find ITS type as well.
|
|
|
|
|
1) Why would I not be doing a code review in VS?
2) Even if I weren't, why does this one fringe case (code reviews for poor coders and not using VS) merit banning var ?
I'm glad that this barring of var works for you, but I still disagree with the premise that this keyword should be universally reviled.
|
|
|
|
|
The goto have it's place and sometime you would need to do complicate your code with extra variables, conditions and loops just to avoid using a goto that would be clearer, faster and simpler.
If you never found the case in those complex loop where you need to go in another one then maybe you don't need it, but It would not judge someone that use a 1 or 2 goto in a program a lazy programmer.
Same for the var, it has it purpose, but not for everday used.
|
|
|
|
|
Then, you don't disagree at all - read the post. I am not saying that var does not have its place, I am saying that var is massively overused, which makes it bad. If it were only used where it is required, then it wouldn't be a problem.
|
|
|
|
|
var is maybe good for debugging.
30 years of coding in Cobol, Dibol, C, C++, C# and even (grunt)Basic I've not used a goto in code.
(Exception, the Main loop in a Basic progy on a TRS80 or something).
Folding for Team 32
|
|
|
|
|
I see the var point made here quite plainly.
However the Goto statement is just another tool in the box.. it has it's place... I'm PRO Goto statement.. but I hardly use them myself.. but I would be a bit annoyed if they weren't around because there are times that they are the best tool for the job... though I agree not frequently.
Know way too many languages... master of none!
|
|
|
|
|
Like var, goto can be sanely used when forcing fall through's in switch statements.
Thanks,
Dave Shaw
History admires the wise, but elevates the brave. - Edmund Morris
|
|
|
|
|
agreed! I am a fan of using them in optimization "scenarios" like that. I try to have like...
...bunch of junk...
goto GetRdun;
...bunch of junk...
...bunch of junk...
goto GetRdun;
...bunch of junk...
LABEL GetRdun;
(So that there is one target if I use it in a function or something... gain the speed benefit, without making pasta! LOL )
Know way too many languages... master of none!
|
|
|
|
|
While your statement is true in some cases, IMHO it's perfectly viable to use
var customers = new List<Customer>();
I personally use it a lot, and never heard any negative remarks.
As mentioned in my article[^] and previous comments, it is all about knowing when to use a tool.
If you want to forbid the var keyword, because it can be abused, you might as well forbid all knives, or even hammers, and maybe airplanes as well, since they all can be abused for another purpose....
|
|
|
|
|
Not forbidding it, because it does have some valid uses. However, there's absolutely no reason to use it across the board like many people are doing.
I agree with your blog post for the most part - all of your arguments about naming and things like that are 100% on, but since I have yet to see someone who only uses var when the exact meaning can be derived from a properly named variable (named for intent, not specifically type), I maintain it is better to enforce that it only be used when it is absolutely needed. And hey, even Microsoft agrees with me on this (as one of your commenters pointed out). Of course, their employees are among the worst offenders (in using var) when it comes to online posts with code samples, but their standards people seem to know what they are talking about.
|
|
|
|
|
(named for intent, not specifically type) <--- That there be an old debate with valid reasons on both sides.
I find in IDE's that offer realtime debugging, name completion and mouse over type explainations... that naming for type is not needed so much..
however in languages and IDE's that are just raw code with perhaps some syntax highlighting... I feel naming for readability makes more sense in my opinion. I can do systemic search-n-replace if the datatype changes... but researching what "customer" means versus rCustomer (record) or oCustomer (some object)... iCustomer (some integer... ) i4Customer (a four byte wide integer) I'll take the basic Hungarian approach - names = definition and type for readability.
Know way too many languages... master of none!
|
|
|
|
|
I wouldn't say developers who use var are lazy. You're right there are some problems with it. At the same time I think there is good uses for it like foreach loops and defining some generic types like
var customers = List<Customer>(); If somebody now reads my code she might not remember after reading declaration that customers is list of Customer, but at least she will know it's some kind of an collection of Customer. I don't think using var is no bad thing; no more than if you name your variables a and b or value1 and value2.
It would be equally confusing if I had
double value1 = double.MaxValue; then several lines of codes (more than one screen) and then
int value2 = value1; and still if reader does not remember that value1 is double she will not notice the error.
So there is good and bad usage for the variables declared with var, but my opinion is that if you name your variables correctly and do not write functions that span several hundreds lines, then using var inside the function declaration, or more likely in shorter scope inside the function, is acceptable.
|
|
|
|
|
Those variable names were obviously NOT real code - you clearly don't have the comprehension to understand that. The problem with your last statement is that poor programmers WILL write functions that are way too long, and poor programmers are those that are going to be prone to overusing something like var (i.e. using it for every variable declaration that they have). Poor programmers are also going to be the ones that see blog posts like those I have referenced and think it's okay to use var everywhere, which will cause the exact problems I talk about. If you do not have to deal with any poor programmers or any code from poor programmers, you either have never worked in a team, live in a fantasy world, or are, in fact, the poor programmer on your team.
|
|
|
|
|
Yes I did understand those were examples, but that was more or less demonstration that there is several ways to make your code bad. One is overuse of var and one is bad variable naming. And from those two bad variable naming is more confusing to me than wise use of var. I also think that demonstrating one bad practice and using other completely different in demonstration is not good way either. Be it just example or not.
Secondly if you think your not poor programmer and everybody who writes one or two or ten bad statements is, you might be in thinking wrongly. I know I write poor code sometimes, if that makes me poor programmer so be it that's far better than think I never write bad code. I've seen last couple of years some programmers that don't use var (some that don't event know what C# 3.0 has added to the language) but have written overlong functions still naming their variables wisely. So that equality of if you write some poor code all your code is poor is not either from the real world.
I still think in narrow scopes it's perfectly fine to use var to declare some types, like generics. Good programmers usually know when to use something and when not, and use language additions wisely. And don't think after reading some comments that somebody is poor programmer and somebody is not. From choosing poor or perfect, I'm more closer to poor. You're right about that, but still seeking to come better. You might be closer to perfect, depends how black and white you look this world.
Some would notice that my bad naming example/comment, is just part of the bad programming; not saying that you took it from production code
One function implementation you write might be perfect and next might be poor, depends who is reading code and the day and work load of the time you write it. That's why we review our code and that's the reality I live in.
modified on Wednesday, June 9, 2010 4:00 AM
|
|
|
|
|
I am sure you will get a lot of situations where var is unavoidable.
That's why var keyword has been introduced in .net.
Just taking one scenario and saying "var is bad" is not justified.
|
|
|
|
|
If you had read the post, you would see that I clearly stated that var does have uses. However, it does not change the fact that the number of times it is misused and overused GREATLY outweighs the number of valid, required uses for var.
|
|
|
|
|
then maybe we should look a good example to use var ?
|
|
|
|
|
Jcmorin wrote: then maybe we should look a good example to use var ?
LINQ is the place where var is used most often, usually like so:
var query = from s in somestorage where s.id == whatever select new {s.Id, s.Name};
What type is query supposed to be? It's not always so clear, especially with anonymous classes. Better to let the compiler handle it.
But, I do agree completely that: var x = 5; is just pure laziness, and bad. The only time I use var outside of LINQ is with things like:
IEnumerable<SuperMegaLongClassNameThatNeverSeemsToEnd> someClass = new ...
This is much more readable, in my opinion:
var someClass = new IEnumerable<SuperMegaLongClass...
That's another place where Resharper excels, because you can use var anywhere you aren't sure, and then tell reshaper to change it for you into the correct type name.
|
|
|
|
|
>> it is misused and overused
In my opinion, that's the rub, in a nutshell. Personally, I try to avoid it like the plague unless absolutely necessary. As you've mentioned, it the makes the code extremely difficult to read. The "switch" statement also accepts a "goto" to jump from one case statement to another, here's an example, another hack I avoid. I have, on rare occasions, found a use for var. But I draw the line with goto. It reminds me too much of my VB 5 days ...shudder...
|
|
|
|