Getting started with Linq, and dealing with the early anti-patterns *sigh*

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"

    select c.CompanyName;

 

foreach (var item in query)

{

    Debug.WriteLine(item.ToString());

}

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"

    select currentItem;

 

foreach (Customer customer in customers)

{

    Debug.WriteLine(customer.ToString());

}

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

    select currentItem;

 

foreach (FileInfo file in files)

{

    Debug.WriteLine(file.ToString());

}

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…

Posted in Linq, Uncategorized

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Archives
Categories

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 2 other followers

%d bloggers like this: