An interesting (or not) thing about C#'s var
-
Yep, I have loved var since its conception. I have heard a lot of complaints, but have found none are valid if a person is in general, not an idiot. The most notable complaint is "I don't know what it is", to which I say, "Who cares"? This usually perplexes the questioner, but then I insist it shouldn't matter what the object is. For one, more oftan (if its a good system) you are working against an interface anyways. They love to respond "Yes but I want to see it". Again I say "Why"? Here is the rub. The person that wrote the original code leaving you with a variable defined by var has hopefully given you enough (just enough and not more than enough) information you need via appropriate naming and usage. Here is a few made up examples that help with the point. This example shows basic naming accomplishes what we need
var connectable = this.Factory.GetConnectable();
...
connectable.Connect();This example shows that the bad naming even with the defined interface will cause the dev/reader to have to back reference
IConnectable c= this.Factory.Get();
...
c.Connect();And this shows you can proper name and not use var, but at a readability cost
IConnectable connectable = this.Factory.GetConnectable();
...
connectable .Connect();OK so simple examples and maybe it is hard to see the points so I will reiterate. In the first (my preference) we enforce clear naming and remove the "Type" for the benifts that you pointed out (no reference needed, updates automatically propagate with NO refactor necessary and many more). In the second example, we see how even with the usage of clear defined type definitions, it comes down to proper naming. The final example shows that combining the proper naming with clear types only adds complexity to the reading. While this is a simple example, one can expect the signatures to get much longer. The type listing becomes unnecessary chrome around the actual logic.
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet. The interesting thing about software is it can not reproduce, until it can.
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> fieldIndexLengthMap = GetMap();
But I still find myself avoiding
varexcept 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,
cp2is like avar-- it has no type definition. Or,sndrandargshere: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
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
-
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... >: |
n.podbielski wrote:
Nothing strange here. It is logical.
Yes, it's logical, but it's also interesting that Intellisense works without the assembly being referenced. Most (if not all) home-grown Intellisense implementations that I've looked at (and I've looked at quite a few recently) parse the using list to figure out what assemblies need to be pulled in, or require that you manually register them. Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
-
n.podbielski wrote:
Nothing strange here. It is logical.
Yes, it's logical, but it's also interesting that Intellisense works without the assembly being referenced. Most (if not all) home-grown Intellisense implementations that I've looked at (and I've looked at quite a few recently) parse the using list to figure out what assemblies need to be pulled in, or require that you manually register them. Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Marc Clifton wrote:
but it's also interesting
If VS intellisense would work from compiled code it probably be like you think it would. But it does not. If is known bug (I think, I experienced it quite often) to have intellisense and compiler goes separate ways (code compiles without problems, but you have red underscore with errors). It is like that because hints have to work even if you code do not compiles or never was compiled (new project i.e.) and both mechanism works on different set of data.
No more Mister Nice Guy... >: |
-
Yep, I have loved var since its conception. I have heard a lot of complaints, but have found none are valid if a person is in general, not an idiot. The most notable complaint is "I don't know what it is", to which I say, "Who cares"? This usually perplexes the questioner, but then I insist it shouldn't matter what the object is. For one, more oftan (if its a good system) you are working against an interface anyways. They love to respond "Yes but I want to see it". Again I say "Why"? Here is the rub. The person that wrote the original code leaving you with a variable defined by var has hopefully given you enough (just enough and not more than enough) information you need via appropriate naming and usage. Here is a few made up examples that help with the point. This example shows basic naming accomplishes what we need
var connectable = this.Factory.GetConnectable();
...
connectable.Connect();This example shows that the bad naming even with the defined interface will cause the dev/reader to have to back reference
IConnectable c= this.Factory.Get();
...
c.Connect();And this shows you can proper name and not use var, but at a readability cost
IConnectable connectable = this.Factory.GetConnectable();
...
connectable .Connect();OK so simple examples and maybe it is hard to see the points so I will reiterate. In the first (my preference) we enforce clear naming and remove the "Type" for the benifts that you pointed out (no reference needed, updates automatically propagate with NO refactor necessary and many more). In the second example, we see how even with the usage of clear defined type definitions, it comes down to proper naming. The final example shows that combining the proper naming with clear types only adds complexity to the reading. While this is a simple example, one can expect the signatures to get much longer. The type listing becomes unnecessary chrome around the actual logic.
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet. The interesting thing about software is it can not reproduce, until it can.
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 :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
-
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 :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
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>>();
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.podbielski wrote:
Nothing strange here. It is logical.
Yes, it's logical, but it's also interesting that Intellisense works without the assembly being referenced. Most (if not all) home-grown Intellisense implementations that I've looked at (and I've looked at quite a few recently) parse the using list to figure out what assemblies need to be pulled in, or require that you manually register them. Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Marc Clifton wrote:
Yes, it's logical, but it's also interesting that Intellisense works without the assembly being referenced.
The assembly is referenced I'd think. The namespace is not declared above via using. var is the same as using the fully qualified type name, so that works fine.
Regards, Nish
Website: www.voidnish.com Blog: voidnish.wordpress.com
-
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>>();
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 :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
-
[disclaimer] OK, this is probably a totally lame post. [/disclaimer] When you use var (or even if you just embed the rvalue as a parameter to another method), you don't need to reference the assembly containing the type.
var prop = rec.GetType().GetProperty(propName);Doesn't requireusing System.Reflection;And Intellisense works just fine. But this:PropertyInfo prop = rec.GetType().GetProperty(propName);Does. Neither does this:object val = Converter.Convert(data, rec.GetType().GetProperty(propName).PropertyType);I find that, well, interesting. (I'm using VS2015, lest anyone even care.) MarcImperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Marc Clifton wrote:
you don't need to reference the assembly containing the type
Wait a second, you mean it does not require referencing assembly or
usingdirective for the namespace?GeoGame for Windows Phone | The Lounge Explained In 5 Minutes
-
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 :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
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
-
Yep, I have loved var since its conception. I have heard a lot of complaints, but have found none are valid if a person is in general, not an idiot. The most notable complaint is "I don't know what it is", to which I say, "Who cares"? This usually perplexes the questioner, but then I insist it shouldn't matter what the object is. For one, more oftan (if its a good system) you are working against an interface anyways. They love to respond "Yes but I want to see it". Again I say "Why"? Here is the rub. The person that wrote the original code leaving you with a variable defined by var has hopefully given you enough (just enough and not more than enough) information you need via appropriate naming and usage. Here is a few made up examples that help with the point. This example shows basic naming accomplishes what we need
var connectable = this.Factory.GetConnectable();
...
connectable.Connect();This example shows that the bad naming even with the defined interface will cause the dev/reader to have to back reference
IConnectable c= this.Factory.Get();
...
c.Connect();And this shows you can proper name and not use var, but at a readability cost
IConnectable connectable = this.Factory.GetConnectable();
...
connectable .Connect();OK so simple examples and maybe it is hard to see the points so I will reiterate. In the first (my preference) we enforce clear naming and remove the "Type" for the benifts that you pointed out (no reference needed, updates automatically propagate with NO refactor necessary and many more). In the second example, we see how even with the usage of clear defined type definitions, it comes down to proper naming. The final example shows that combining the proper naming with clear types only adds complexity to the reading. While this is a simple example, one can expect the signatures to get much longer. The type listing becomes unnecessary chrome around the actual logic.
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet. The interesting thing about software is it can not reproduce, until it can.
The only time
varreally hurt was when converting fromIEnumerabletoIQueryable. Something like the following:var things = context.Things.ToList(); // Database call here.
// use things without further database calls.
Now what happened, someone removed the call to
ToList!IEnumerablebecame anIQueryable(which actually IS anIEnumerable). Nothing broke, it's just that with every usage of thethingsvariable a database call was made. Things got a lot slower. Until someone noticed the boo boo. I'm also not a fan of usingvarin "generic" code. Something likeIObjectGetter.Get. At least let me know what type of objectGetis going to return by not usingvar. That's why I don't usevar. I often don't really care about the type that's returned, but I want to see you THOUGHT about what type you expected.Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
Yep, I have loved var since its conception. I have heard a lot of complaints, but have found none are valid if a person is in general, not an idiot. The most notable complaint is "I don't know what it is", to which I say, "Who cares"? This usually perplexes the questioner, but then I insist it shouldn't matter what the object is. For one, more oftan (if its a good system) you are working against an interface anyways. They love to respond "Yes but I want to see it". Again I say "Why"? Here is the rub. The person that wrote the original code leaving you with a variable defined by var has hopefully given you enough (just enough and not more than enough) information you need via appropriate naming and usage. Here is a few made up examples that help with the point. This example shows basic naming accomplishes what we need
var connectable = this.Factory.GetConnectable();
...
connectable.Connect();This example shows that the bad naming even with the defined interface will cause the dev/reader to have to back reference
IConnectable c= this.Factory.Get();
...
c.Connect();And this shows you can proper name and not use var, but at a readability cost
IConnectable connectable = this.Factory.GetConnectable();
...
connectable .Connect();OK so simple examples and maybe it is hard to see the points so I will reiterate. In the first (my preference) we enforce clear naming and remove the "Type" for the benifts that you pointed out (no reference needed, updates automatically propagate with NO refactor necessary and many more). In the second example, we see how even with the usage of clear defined type definitions, it comes down to proper naming. The final example shows that combining the proper naming with clear types only adds complexity to the reading. While this is a simple example, one can expect the signatures to get much longer. The type listing becomes unnecessary chrome around the actual logic.
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet. The interesting thing about software is it can not reproduce, until it can.
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 fucking 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. -
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 :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
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.
Actually that is why its good.
Eddy Vluggen wrote:
var con = (IDbConnection) Factory.GetConnectable();
So because you casted it and now have a run time failure it is var's fault? Sorry, you are wrong. The fault is on the guy that casted it when it should have returned as the needed type for the method it is in. Again, don't be an idiot and it works fine. There should be no need to cast, and if there is you should protect your calls to the object after you casted it.
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet. The interesting thing about software is it can not reproduce, until it can.
-
The only time
varreally hurt was when converting fromIEnumerabletoIQueryable. Something like the following:var things = context.Things.ToList(); // Database call here.
// use things without further database calls.
Now what happened, someone removed the call to
ToList!IEnumerablebecame anIQueryable(which actually IS anIEnumerable). Nothing broke, it's just that with every usage of thethingsvariable a database call was made. Things got a lot slower. Until someone noticed the boo boo. I'm also not a fan of usingvarin "generic" code. Something likeIObjectGetter.Get. At least let me know what type of objectGetis going to return by not usingvar. That's why I don't usevar. I often don't really care about the type that's returned, but I want to see you THOUGHT about what type you expected.Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
This is again an example of someone not knowing what they are doing. You are blaiming var because you had an escape. First off, the real blame is the guy that changed it and shouldnt have. Secondly, the escape happened not because you used var but because you did not have good perf testing prior to release. Stop blaiming var for your problems. var is just a method of keeping syntax clean. Yes, it takes good practice but having bad practice doesn't mean var was the problem.
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet. The interesting thing about software is it can not reproduce, until it can.
-
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 fucking 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.CDP1802 wrote:
How about investing a little more thought into what we are doing and how we do it?
That is in fact my point. Those that have issues with var (as you clearly do) do not have an issue with it, but that it makes the bad practices even worse. The fact is, you are working with someone with very bad practices. That does NOT make var bad practice. It just amplifies his bad practice.
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet. The interesting thing about software is it can not reproduce, until it can.
-
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.
Actually that is why its good.
Eddy Vluggen wrote:
var con = (IDbConnection) Factory.GetConnectable();
So because you casted it and now have a run time failure it is var's fault? Sorry, you are wrong. The fault is on the guy that casted it when it should have returned as the needed type for the method it is in. Again, don't be an idiot and it works fine. There should be no need to cast, and if there is you should protect your calls to the object after you casted it.
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet. The interesting thing about software is it can not reproduce, until it can.
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 :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
-
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 :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
Eddy Vluggen wrote:
It is if you dislike strong typing, in which case you might prefer VB.NET :)
X|
Eddy Vluggen wrote:
No, I did not state that; merely that it would be redundant to repeat the type instead of using var.
THen I misunderstood your example. Not sure what you were trying to show as the failure of using var in that case...
Eddy Vluggen wrote:
Do elaborate and please explain what in your eyes I would have blamed on var?
It seemed like you were implying you would hit an exception with return differences. So my point was, the return differences would have been fine if you did not cast.
Eddy Vluggen wrote:
You go ahead and complain with Microsoft, I'll be waiting here for the result.
That's not MS's fault. Tis the point. That is the fault of the bad programmer. You can't fix stupid, but you can shield yourself from it. From that I get why people have had bad run ins with var. But to my point, there was usually something else actually at fault AND there was a more accepted practice at finding the error.
Eddy Vluggen wrote:
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.
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. Sorry, that is just wrong. You haven't made your case at all. var works great. Bad programmers will be bad programmers. You meantioned VB.Net and honestly that is part of its problem too. Sooooo many VB programmers were in fact wanna be programmers (NOT ALL!!!) which caused normal programmers to witness this barrage of atrocities committed in the name of VB.Net VB can be fine. I simply do not like it, but that is out because I do not use it. One could just as easily say C or java or Ruby is bad because I am not using it regularly. In the case of VB though it had a flood of bad programmers that created systems that have created a stigmata on the language. Maybe this is happening with var too.
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank ou
-
Eddy Vluggen wrote:
It is if you dislike strong typing, in which case you might prefer VB.NET :)
X|
Eddy Vluggen wrote:
No, I did not state that; merely that it would be redundant to repeat the type instead of using var.
THen I misunderstood your example. Not sure what you were trying to show as the failure of using var in that case...
Eddy Vluggen wrote:
Do elaborate and please explain what in your eyes I would have blamed on var?
It seemed like you were implying you would hit an exception with return differences. So my point was, the return differences would have been fine if you did not cast.
Eddy Vluggen wrote:
You go ahead and complain with Microsoft, I'll be waiting here for the result.
That's not MS's fault. Tis the point. That is the fault of the bad programmer. You can't fix stupid, but you can shield yourself from it. From that I get why people have had bad run ins with var. But to my point, there was usually something else actually at fault AND there was a more accepted practice at finding the error.
Eddy Vluggen wrote:
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.
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. Sorry, that is just wrong. You haven't made your case at all. var works great. Bad programmers will be bad programmers. You meantioned VB.Net and honestly that is part of its problem too. Sooooo many VB programmers were in fact wanna be programmers (NOT ALL!!!) which caused normal programmers to witness this barrage of atrocities committed in the name of VB.Net VB can be fine. I simply do not like it, but that is out because I do not use it. One could just as easily say C or java or Ruby is bad because I am not using it regularly. In the case of VB though it had a flood of bad programmers that created systems that have created a stigmata on the language. Maybe this is happening with var too.
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank ou
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 :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
-
This is again an example of someone not knowing what they are doing. You are blaiming var because you had an escape. First off, the real blame is the guy that changed it and shouldnt have. Secondly, the escape happened not because you used var but because you did not have good perf testing prior to release. Stop blaiming var for your problems. var is just a method of keeping syntax clean. Yes, it takes good practice but having bad practice doesn't mean var was the problem.
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet. The interesting thing about software is it can not reproduce, until it can.
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.Thingsand 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 :doh: 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.
Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
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 :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
Eddy Vluggen wrote:
The cast is there to specifically say which interface is expected.
Yes, but why? Why do you need that? It is not necessary and was my point. By placing the cast you create a potential run time error that was not even necessary.
Eddy Vluggen wrote:
That argument is pro weak typing, isn't it?
Yes. There is no need for strict typing in MANY cases (no not all). And a good programmer should know how to use that to their advantage....
Eddy Vluggen wrote:
The DbProvider returns a class, but I only use the interface - so when I can be specific about which type I expect, I do.
OK. Do you know what an adapter is? (rhetorical question actually)
Eddy Vluggen wrote:
I merely state that not being an idiot would mean that you verify, and not generalize.
Not sure what you are saying, but yeah you should have verification. Most of the people that posted issues with var seemed to blame it for 2 things 1. The escaped failure 2. The fact the failure escaped Neither are true and simple verification procedures and tests would have been far more appropriate. Is this a generalization. Yep, but that is what I am seeing in all of the respondents and near all conversations I have had with people that dislike var.
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet. The interesting thing about software is it can not reproduce, until it can.
-
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.Thingsand 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 :doh: 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.
Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
Sander Rossel wrote:
I believe the query changed, so that person basically changed everything after
Context.Thingsand just forgot the call to ToList.Your failure is staring you in the face, but you keep wanting to blame var. Also, testing is not just theoretical practice....
Sander Rossel wrote:
Yeah, neither us nor our customer can afford a second environment that's exactly like our production environment
Sounds like a scapegoat to me, but OK. Not sure if you have ever listened to some of the MS evangelicals talk about their releases and test procedures. YEs, billion dollar company. They also happen to offer "free" server space to MSDN subscribers. Your statement was way to vague to know what you are testing, but I to use an excuse of it costing too much is proven to be wrong. I can find out countless articles and examples that show testing up front is far cheaper than releasing with an issue and having to fix in production. But I am sure you know that....
Sander Rossel wrote:
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.
Ummmm no. I think you are making assumptions about your IEnumerble from using it with local memory (e.g. using it when it was on a List in memory). It follows the correct behavior as written in IEnumerable, but again you are being vague so maybe you have an actual example you care to share.
Sander Rossel wrote:
The only REAL reason to use var, where you actually HAVE to, is when you use anonymous types.
ACtually no. As the OP stated, there are others. His example is actually I good one that I have taken advantage of many times. Specifically, you do NOT need references to the namespace or library even. Anyway, this horse is a bit bloody. I have found var is a religious argument, but I have also brought many over to "the dark side" through diligent coding. I have yet to see someone be persuaded the opposite, for as I said most people use it as a scapegoat for some other failure and lack of testing.
