|
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
|
|
|
|
|
|
|
Don't confuse var with dynamic.
Jeremy Falcon
|
|
|
|
|
Just to get this out of the way, I failed the TopTal[^] application.
How did I even find TopTal? In the CP newsletter!
TopTal's primary screening process is to use Codility[^] to see how good your skills are.
Now, the 90 minute timed test at Codility asked me to solve three problems:
- the point in which in an array, the count of X from the left != count of X from the right.
- given some bit encoding scheme, convert N to -N with the least number of bits.
- the optimum number of moves a chess knight must make to get from (0, 0) to (m, n)
Regarding the last, someone here at posted about that idiocy of that actually testing coding skills.
In fact, they all are extremely poor tests of skill. Each (particularly #2 and #3) probably involve a simple trick to figure it out, and if you don't know the trick (like me) you're spending a lot of time just thinking about the problem. At least I was.
How exactly does solving an arbitrary algorithm test coding skills? How does it demonstrate good OOP practices, or DB architecture skills, or an understanding of Linq, or really much else other than "getting the trick?"
After working hard at #1, writing assertions, commenting the code, testing edge cases, optimizing the algorithm for O(1) performance, I realized I had spent an hour on one stupid problem. That left 30 minutes for the remaining two. Riiiight.
Now, Codility says something like "don't worry if you don't complete all three tests, just show your best work, even if you only complete one test."
And then the test results are amusing. The requirements don't state what to do with incorrect inputs into the "solution" method, and they clearly can't handle exceptions being thrown -- I noticed my score in their example test dropped dramatically when I used exceptions.
Now to TopTal. I got an email rejecting me because my score was low. It was pretty darn obvious that no one had even bothered to look at my code! That REALLY  me.
TopTal: 
Codility:
Anyone that uses Codility:
Sadly, this sort of crap testing methods is probably going to be used more and more.
Oh, and Codility has an "honor system" where you won't talk about their tests. F*** them. They should come up with better tests!
Marc
|
|
|
|
|
Marc Clifton wrote: How exactly does solving an arbitrary algorithm test coding skills? How does it demonstrate good OOP practices, or DB architecture skills, or an understanding of Linq, or really much else other than "getting the trick?"
This is a great question. Is there any way for a site to determine your level of ability without having some human intervention? Can a test be given which is graded by a computer and accurately tests someone's skills?
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
RyanDev wrote: without having some human intervention?
Exactly!
Marc
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
