The Laziness of LINQ
-
Quote:
(esp. when more complex than the example)
But that's the key. We're not talking about thing more complex.
Truth, James
-
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.
-
Sorry, `item` is about as meaningful as `t`. Except typing out item is more verbose.
-
We've spent 20 years trying to teach developers not to use variables like
i,jandk. 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
Yes, you are but so am I. I guess that linq is all about lazyness, don't you think? ;-) Instead of using single char variable names I mostly use a short descriptive name for the type like 'car' or 'person'. In this case I'd use 'ivpair' instead of sortItem, since the OrderBy is clear enough for me. Also 'item' adds no more clarity than 'i' or 't' because the item type is irrelevant for sorting. The lazyness is IMHO encouraged by the numerous examples available and course exercises; they tend to save on keystrokes and sacrifice maintainance. Can't change the world though...
-
Why is that mate? It helps with little to no compromise, does it not?
Dictionary> someDictionary = new Dictionary>()
vs.
var someDictionary = new Dictionary>()
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
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 = 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
-
We've spent 20 years trying to teach developers not to use variables like
i,jandk. 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