|
|
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... >: |
|
|
|
|
|
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
|
|
|
|
|
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... >: |
|
|
|
|
|
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.
|
|
|
|
|
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 using directive for the namespace?
|
|
|
|
|
var seem way too close to the VB6 variant type so I have trouble typing it. The same applies for GOTO, just can't bring myself to use them.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Mycroft Holmes wrote: var seem way too close to the VB6 variant type
A common misconception.
var doesn't mean that your variable is untyped, or typed as object. It just means that the compiler decides what type the variable should be based on the value assigned to it when it is declared.
var s = "Hello";
s = 42;
Totally unlike the Variant type, where the variable could contain anything, and all calls were late-bound:
Dim s As Variant
s = "Hello"
s = 42
Set s = New ADODB.Connection
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
I don't like var. If it's so goddamn wonderful, why require its use at all? Why bother even defining types at all?
If I wanted to code like that, I'd use VB.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
John Simmons / outlaw programmer wrote: Why bother even defining types at all?
Because var doesn't mean "untyped". It means, "the type of this variable is obvious to the compiler, so I don't need to bother writing it".
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
