|
Ixodes ricinus?
PooperPig - Coming Soon
|
|
|
|
|
|
_Maxxx_ wrote: Clue: c'mon you buggers, don't be mean!
I thought I'd got it until then! Now I'm confused...
I still think it's a game, for two people...Hmm...
Is it Knifey-Spoony?
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
OriginalGriff wrote: a game, for two people
Shagg?
PooperPig - Coming Soon
|
|
|
|
|
We've spent 20 years trying to teach developers not to use variables like i,j and k. So why is it that every time I see some LINQ code it's like this:
return source.Select(t => new
{
Index = rand.Next(),
Value = t
})
.OrderBy(p => p.Index)
.Select(p => p.Value);
Is it really that painful to do
return source.Select(item => new
{
Index = randomiser.Next(),
Value = item
})
.OrderBy(sortItem => sortItem.Index)
.Select(sortItem => sortItem.Value);
Or am I just too old and grumpy for my own good.
cheers
Chris Maunder
|
|
|
|
|
I disagree, the single-letter name (in a tiny scope) clearly indicates that the reader needn't spend any extra time thinking about the value. It's a throw-away.
|
|
|
|
|
PIEBALDconsult wrote: clearly indicates that the reader needn't spend any extra time thinking about the value. It's a throw-away.
Which is fine when you're writing it, or just reading through the code - but not when you're trying to debug non working code (esp. when more complex than the example) you need to stop and decipher.
PooperPig - Coming Soon
|
|
|
|
|
Quote: (esp. when more complex than the example)
But that's the key. We're not talking about thing more complex.
Truth,
James
|
|
|
|
|
I was
I think the op was talking in general, giving a simple example .
PooperPig - Coming Soon
|
|
|
|
|
I love when someone writes a library and uses single-letters for the parameters. It makes finding out what the function actually needs very difficult.
|
|
|
|
|
Agree completey, and I will add that if x,y,z,etc bother you I highly doubt the other devs on the team will care if you refactor the 'x' into 'theNewFooToInsert'. Since the linq statement is fully enclosed the refactor can be done 100% using the tools built into VS or ReSharper... making it arbitrarily easy to do.
|
|
|
|
|
Haha, if I touch the code, I refactor it just in the opposite direction!
sortItem => i ! 
|
|
|
|
|
Sorry, item is about as meaningful as t. Except typing out item is more verbose.
|
|
|
|
|
|
We can only hope they are stuck maintaining their own code.
I loathe the lazy use of var.
|
|
|
|
|
Why is that mate? It helps with little to no compromise, does it not?
Dictionary<string, IList<Person>> someDictionary = new Dictionary<string, IList<Person>>()
vs.
var someDictionary = new Dictionary<string, IList<Person>>()
even
var order = GetOrder(orderId)
is hinting with (1) the variable name and (2) the function name
and
var users = account.Select(a => new { Name = a.FullName, Role = a.Role } )
is simply cool.
Or are you referring to things like the following?
var money = 123m
|
|
|
|
|
Quote: var money = 123m
One of my pet peeves 
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
It compromises all over the place!
It saves you a couple of seconds of typing, but makes it harder to maintain because you can't just glance at the code and see what type a variable is.
When you see code like:
var order = GetOrder(orderId); You can't trust that order is of type Order because you are relying on the previous programmer (who you know to be lazy) to have still returned an Order from his method and not something totally different but been too lazy to change the name!
Seeing it as:
Order order = GetOrder(orderId); Make it absolutely obvious at a glance - and will immediately throw a compiler error if you change the method return type. Or if the wrong using block has been added and GetOrder comes from the wrong assembly alltogether.
Yes, these are extreme cases - but an extra second or two of your time and it would be clear.
var has it's place, and it's vital for Linq - but that's where it should stay! 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
The entire point of
var order = GetOrder(orderId);
is to be able to change the return type of your method, without having to track back through all the usages of that method and update all of that code as well.
That said this is the one usage of var where I get a little uncomfortable for the same reasons you said.
Generally speaking code using var as opposed to the actual type is easier to work on, less touch points while refactoring.
|
|
|
|
|
No, it is not.
I really want committed and released code to break on that line on a future change of the GetOrder return type. While developing 'var' is my friend and when done the "use explicit type" refactor option is. 
|
|
|
|
|
OriginalGriff wrote: been too lazy to change the name!
Ha!
The other day I wrote a GetType sort of method, it returned a Type. But then I decided to have it return a ConstructorInfo instead -- but I didn't change the name!  (Until the following day.)
|
|
|
|
|
|
I have to agree to an extent. Consider the following:
var user = new User();
This is fine imho because it explicitly states the type on the right. I don't mind seeing types on the right with a var on the declaration of type because it is still right there.
User user = new User();
This just feels unnecessary to me because you are stating it in two places;
var user = GetUser(userId);
I don't like this one either as the type of user can be assumed, but isn't immediately obvious in more complicated examples. In this example, sure, you can assume user, but what if you were actually returning:
IQueryable<User> user = GetUser(userId);
because for some odd business reason, a user consisted of multiple users. It is still a single base user in this example that logged in, but he has multiple user objects. Returning the IQueryable allows us to further filter afterwards, but it isn't obvious.
So, my own idea of a go to is if it is explicitly stated on the right, var on the left is fine. If not, then no. Even if it appears to be an obvious return value, you don't truly know unless you have intimate knowledge of the code.
Steve
|
|
|
|
|
Everyone prefers a minified version of code, you know...
You have just been Sharapova'd.
|
|
|
|
|
Agent__007 wrote: Everyone prefers a minified version of code
Exactly. I removed the space bar from my keyboard because I never use it. 
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
