|
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
|
|
|
|
|
(Automated) Function Point Analysis as a measure of the "scope" / magnitude of the applications one has designed and / or developed.
Is designing and building entire mission-critical "systems" "better" than being good at (just) algorithms? Who needs who?
|
|
|
|
|
I understand your frustration... is someone being tested on their ability to write clean code that works, or their ability to implement a particular algorithm? In this web based world, information is generally readily available and we are no longer required to remember the exact syntax of an expression; we ARE expected to know how to use it and where to find information on it, however.
I remember when I started in programming, all 'tests' were math based assignments that didn't test coding ability, they tested your understanding of the underlying math problem.
|
|
|
|
|
I'm surprised you took the test, really. Were you just curious?
Marc Clifton wrote: I got an email rejecting me
Feels weird having some piece of sh*t company reject you, when you know that you are a bad ass. Been there, done that - lesson(s) learned.
|
|
|
|
|
Slacker007 wrote: Were you just curious?
Yup. I didn't have high expectations, I figured most likely they would fit into the "lots of talk but can't even walk" category.
Marc
|
|
|
|
|
Marc Clifton wrote: 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.
And so it should Exceptions are just that, you shouldn't use them for things that are expected as they are very expensive to create. When it comes to user input you shouldn't rely on exceptions to check if the inputs are valid and you shouldn't throw exceptions when the input is invalid, you should handle these things through other means.
After looking at the kind of questions on that site I have to admit I wouldn't fancy being made to sit that test. It seems to be testing quite a narrow type of programming that not everyone does, and that not every job calls for. I see the merits in what they're doing though, they are often testing things you don't think are important in coding but are.
|
|
|
|
|
F-ES Sitecore wrote: When it comes to user input you shouldn't rely on exceptions to check if the inputs are valid and you shouldn't throw exceptions when the input is invalid, you should handle these things through other means.
Of course, but this wasn't user input, it more like "are the parameters meeting the contract of the function" where I expect the parameters to be prevalidated.
But the telling point was, why they specified things like the array would be between 0 and 100,000 (inclusive) and the numbers would be between 1 and 100,000 (inclusive) they didn't say what the return value should be if the inputs were wrong!
Ultimately, I have no real beef with a test like that as long as there is a follow up discussion. Which there wasn't.
Marc
|
|
|
|