|
|
Great points. And you can also mouse over the var to see its type.
And the readability definitely comes to full expression when you have something like this:
Dictionary<string, Tuple<int, int>> fieldIndexLengthMap = GetMap();
But I still find myself avoiding var except in specific cases - for example when I get a collection and then immediately iterate over it:
var cps = el.GetConnectionPoints().Where(cp2 => cp2.Type == c.ElementConnectionPoint.Type);
cps.ForEach(cp => c.ToElement.MoveAnchor(cp, c.ToConnectionPoint));
One argument one might use for people (like me!) who say "but I want to know what type it is!" is to ask them if they use Linq or anonymous methods. In the above example, cp2 is like a var -- it has no type definition. Or, sndr and args here:
mnuImport.Click += (sndr, args) =>
{
canvasController.DeselectCurrentSelectedElements();
mnuImport_Click(sndr, args);
};
Which, oddly, makes me question why I'm so gun shy myself about var.
Marc
|
|
|
|
|
Simple case against that reasoning; var does not just hide the type, it accepts every type - and that might change, without going noticed when using var. When you specify which interface you are using you don't run into that problem.
Then again, that is covered by the first paragraph in your post, by the "not being an idiot" bit. Combine both, and you'd get below example;
var con = (IDbConnection) Factory.GetConnectable(); If you are talking about readability, I'd recommend against stating the obvious and ommitting "this" until it is actually required.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: Simple case against that reasoning; var does not just hide the type, it accepts every type - and that might change, without going noticed when using var. When you specify which interface you are using you don't run into that problem.
Yup, although much of the time when you change the type you do end up getting breakage that needs fixed to compile anyway.
Like Marc, storing the dumpster fires that linq often returns as temporary/local/ephemeral variables (if I want to persist it I force it into something non-retarded) is one of the two places I normally use var.
The other is when declaring my own dumpster fire generics because in these cases the type information is already explicitly given 10 or 30 characters to the right..
var whyGodWhy = new Dictionary<string, tuple<int, List<myType>>>();
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
Dan Neely wrote: The other is when declaring my own dumpster fire generics because in these cases the type information is already explicitly given 10 or 30 characters to the right..
Yup, that's the DRY version.
Now some people might put such an example in our "Weird and Wonderful" section, but repeating the same type-information without any benefit would indeed be worse 
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: Dan Neely wrote: The other is when declaring my own dumpster fire generics because in these cases the type information is already explicitly given 10 or 30 characters to the right..
Yup, that's the DRY version.
Now some people might put such an example in our "Weird and Wonderful" section,
If it was undocumented or part of a public API I'd probably be one of them. For something internal to its user a paragraph unpacking what the structure is is lighter weight than a the pile of wrapper classes I'd need if it was publicly accessible.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
|
N_tro_P wrote: Actually that is why its good.
It is if you dislike strong typing, in which case you might prefer VB.NET
N_tro_P wrote: So because you casted it and now have a run time failure it is var's fault?
No, I did not state that; merely that it would be redundant to repeat the type instead of using var.
Do elaborate and please explain what in your eyes I would have blamed on var?
N_tro_P wrote: The fault is on the guy that casted it when it should have returned as the needed type for the method it is in.
You go ahead and complain with Microsoft, I'll be waiting here for the result.
N_tro_P wrote: Again, don't be an idiot and it works fine.
The not being an idiot part would IMO be that you verify that you get what you expect, and not to use "var" as a "variant" from VB.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
|
N_tro_P wrote: So my point was, the return differences would have been fine if you did not cast.
The cast is there to specifically say which interface is expected.
N_tro_P wrote: So my point was, the return differences would have been fine if you did not cast.
That argument is pro weak typing, isn't it?
N_tro_P wrote: That's not MS's fault. Tis the point. That is the fault of the bad programmer.
The DbProvider returns a class, but I only use the interface - so when I can be specific about which type I expect, I do.
N_tro_P wrote: But now you just used circular logic. You are saying it is bad because people that use it are bad, and people that use it are bad because it is bad.
No, again, you are reading what is not there. I merely state that not being an idiot would mean that you verify, and not generalize.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
|
N_tro_P wrote: By placing the cast you create a potential run time error that was not even necessary
At run-time? 
N_tro_P wrote: (rhetorical question actually)
Yeah, that helps clarifying the topic 
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
|
N_tro_P wrote: Are you seriously having issues over a hyphen
No. Just the difference with compile-time
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
The only time var really hurt was when converting from IEnumerable to IQueryable.
Something like the following:
var things = context.Things.ToList();
Now what happened, someone removed the call to ToList!
IEnumerable became an IQueryable (which actually IS an IEnumerable).
Nothing broke, it's just that with every usage of the things variable a database call was made.
Things got a lot slower.
Until someone noticed the boo boo.
I'm also not a fan of using var in "generic" code.
Something like IObjectGetter.Get. At least let me know what type of object Get is going to return by not using var.
That's why I don't use var.
I often don't really care about the type that's returned, but I want to see you THOUGHT about what type you expected.
|
|
|
|
|
|
N_tro_P wrote: This is again an example of someone not knowing what they are doing
Or someone who knew fully well what they did, but just missed it. I believe the query changed, so that person basically changed everything after Context.Things and just forgot the call to ToList. The person may have been me, I couldn't say. I was the one to fix it though.
N_tro_P wrote: good perf testing prior to release
Yeah, neither us nor our customer can afford a second environment that's exactly like our production environment 
It worked fine in tests.
N_tro_P wrote: Stop blaiming var for your problems
I actually blame IQueryable that looks like an IEnumerable, but is really something very different. IQueryable quaks like a duck and walks like a duck, but isn't actually a duck. IQueryable breaks the Liskov's Substitution Principle (the L in SOLID) that states that any super class must behave like its base class.
Only by not using var we can catch such by-design-quirks.
The only REAL reason to use var, where you actually HAVE to, is when you use anonymous types.
|
|
|
|
|
|
N_tro_P wrote: I have found var is a religious argument
Sounds pretty religious to you.
I've pointed out some scenarios where NOT using var may help in catching errors early and all you did is call me a failure and a bad programmer who doesn't know what he's doing and compare free MSDN server space to actual production environments.
I actually checked if you were our regular troll, but you have a little too much rep for that. Seems you're just bad mannered.
I'm quite done discussing this with you.
I do use var though. Probably a lot more often than you don't 
|
|
|
|
|
Trust me, I've already learned that N_tro_P simply does nothing but call everyone stupid and argues. You can't win with someone on a podium thinking he's better than everyone.
For what it's worth, I'm very pro var and I still agree with your points. I'll still use var personally, but I still agree with your points. So rest assured, there are pro var people out there that do listen. 
Jeremy Falcon
|
|
|
|
|
Ahhh... The sound of reason, I've missed it in these parts
I'm not pro-var and not anti-var, not sure how var I'll go
|
|
|
|
|
N_tro_P wrote: I have heard a lot of complaints, but have found none are valid if a person is in general, not an idiot.
I prefer to stay a general idiot then. The kid that wrote the code I cleaned up today drank the same coolaid. Var all over the place, including many unused and forgotten variables. He obviously really did not care about types or know how to deal with them. Also some cut and paste redundancy, endless fully qualified namespaces without any need. All that and much more in the code behind of a WinForm.
I refactored about 85% of that away or into other layers. The remaining code does not only work better. It has become even more readable because it's only a tiny fraction of what it was before. So how about not obscessing about readability or countless 'this' or mile long namespaces? How about investing a little more thought into what we are doing and how we do it?
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
|
I'm with you on var, I use it myself when the type is obvious. But this statement
N_tro_P wrote: It just amplifies his bad practice.
Is the only really cogent argument against using var.
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
Marc Clifton wrote: totally lame post
A bit.
If you are defining variable without type it is exactly the same as last returned value from method. If not you have to have say what type exactly you are expecting. After all you may define you own type PropertyInfo and have implicit conversion from .NET one...
Nothing strange here. It is logical.
No more Mister Nice Guy... >: |
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
