The Laziness of LINQ
-
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
orderis 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
usingblock 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.varhas it's place, and it's vital for Linq - but that's where it should stay! :laugh: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.
-
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.
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.
-
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
This isn't isolated to LINQ. You see the same behavior in for/foreach loops as well. The only time I use single letters is when the variable is for an index.
Scott E. Corbett
-
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
I agree with you on the first Select because there's a little complexity in that lambda, but for the OrderBy and second Select, its one line of code, and if it isn't obvious what the parameter represents and how its being used, then a longer variable name isn't going to help the reader much. Personally, for those one-liners, I prefer the simple 'p' argument -- less for my eye to read and my brain to parse (and ignore), which means I reach understanding of the code a lot faster.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
-
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
orderis 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
usingblock 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.varhas it's place, and it's vital for Linq - but that's where it should stay! :laugh:Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
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! :-D (Until the following day.)
-
If it's a single lambda parameter, and its use is limited to a few lines, I nearly always only use a one char parameter, like:
var bachelors = _people.Where(p => !p.IsMarried);
I'm also a one letter man with basic loops.
iandjall the way.No object is so beautiful that, under certain conditions, it will not look ugly. - Oscar Wilde
Brady Kelly wrote:
var bachelors = _people.Where(p => !p.IsMarried);
Generally, that's how I code, also. I specifically don't code that way when the LINQ code involves joins across a series of sources/tables. The
(a,b)=>
can get really messy, esp. if you need
(a,b)=> new {}
multiple times.
vuolsi così colà dove si puote ciò che si vuole, e più non dimandare --The answer to Minos and any question of "Why are we doing it this way?"
-
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
I have always attributed this to the "it's a sample" mentatility. In samples you variables named myObj and newVar and stuff. You should not name things like that in production code, and neither should you use single letter small scope variables. While I have seen both in production code (really, you named the search parameters myString?), I discourage their use (even in linq) in favor of more descriptive names. Perhaps we should insist on better quality examples for teaching these technologies to help instill better habits in new and learning programmers.
-
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
