As I prep for the .NET 3.5 upgrade exams, I need to bone-up on Linq (among a few other things). So, now that the spring semester is officially over, this is my next big thing.
So I crack a book and what do I see off the bat, something like this:
var query =
from c in Customers
where c.Country == "Italy"
foreach (var item in query)
Really Microsoft? Have we learned nothing in the past 20 years? So many things were on a good roll, and then Linq comes crashing in with this. What is my problem? Let me start a list:
- Why use “var” when you darn-well know the data type. Why not just using System.Object if you don’t like strong-typing? Or I hear the “Variant” is making it’s way back to .NET, perhaps that will do!
- Why name…. whatever it is that “c” does – why name that “c”? and what IS that variable?
- Overall, the default signature of how everyone is using Linq, is inherently not intuitive. As someone quite new to Linq, I didn’t know what “query” was, and I didn’t know what “c” was (in terms of data types). That’s bad. That’s not intuitive, and in today’s day-and-age, it’s extremely disappointing and not necessary. We know better!
Put another way, I’m your customer, Microsoft – and I’m new to this technology, and right-off the bat it doesn’t make sense. Not necessarily the technology, but the naming standards everyone is using, makes it harder than it has to be. This is particularly obvious to me because last night I watched a few more videos on Windows Azure and SQL Azure, and I was just giggling as I was following along, because everything was just so obvious, intuitive, and I could probably even have guessed the name of some of those classes, because it was just that obvious. When you write a component, a technology, or whatever – you should strive for this – and Microsoft hits the mark almost every time too! Perhaps that’s why I’m frustrated.
So, for anyone else new to Linq, let’s try to untangle the early anti-patterns. This is what I’ve learned so far:
“var” is a strongly-typed data type that is determined at run-time, but is enforced, presumably. However, because it is a weakly-typed construct at design-time, that means that developers can miss bugs that the compiler would normally catch – which is a bad thing. Unless I’m missing something (and I KEEP asking this question, please let me know if I am!) – this whole fad of weak-typing is really just a horrible idea. Weak-typing takes the power away from the compiler to check and enforce types, and pushing those potential bugs to be run-time problems. This is inherently a bad idea – even if it is for the ultimate purpose of letting a developer develop faster (does it really save that much time?).
Anyhow – the “c” above, is kind of like a reference to the “current row” of data that you are dealing with. If it’s a collection, it’s the current item; if it’s a table, it’s the current row.
So, the obvious and intuitive answer in my head is to be a bit more explicit, to everyone’s benefit:
IEnumerable<Customer> customers =
from currentItem in sourceCustomers
where currentItem.LastName == "Doe"
foreach (Customer customer in customers)
Now, I know what “customers” is, and “currentItem”, as a standard, in all Linq queries reminds me that I’m operating on the current value or current record of data in the “sourceCustomers”, in this case. Here’s the same naming standard in another example:
string tempPath = Path.GetTempPath();
DirectoryInfo directoryInfo = new DirectoryInfo(tempPath);
FileInfo sourceFiles = directoryInfo.GetFiles();
IEnumerable<FileInfo> files =
from currentItem in sourceFiles
where currentItem.Length > 10000
orderby currentItem.Length descending
foreach (FileInfo file in files)
Maybe it’s just me, but I find this much easier to understand. I imagine this would help much more, when you are dealing with significantly more complex Linq statements.
I guess the reason I’m so disappointed in what I’m finding written up on Linq, is that Microsoft was always one of the better vendors in terms of trying to simplify things and make them simple. However, what I see with Linq, it’s like the syntax and early naming standards are from the bad-old-days of Perl and C++. I continue to hope that now that we know better, we can do better! Well, I’m going to try to that at least in my own code.
Who knows, i might be missing some valid point here – and if I am, I’ll post back here again. Meanwhile, I’ll try to post other useful Linq topics up here for you (and also for future-me, so I have a place on the Internet to reference them) as I continue to learn…