Grammar Nazis will point out that I’ve made a syntactical error in the title.

Software developers will also be scratching their heads, wondering what I was trying to convey by that title, and might even go so far as to side with the Grammar Nazis.

Everything will make sense, once you reach the end of this article, so fasten your seatbelts.

We are about to explore some pretty neat stuff that will boost your productivity and bring you closer to becoming an Ace RPA Developer.

Select and Where are Not the Same

Because if they were, then they’d share the same name.

Why give it two separate names when they share the same definition? Wouldn’t that be redundant?

That being said, the English language has several words which share the same meaning.

Tools can be instruments, and instruments can be devices which can also be any sort of contraption.

English is filled with all sorts of universal sets referencing or containing other universal sets, which makes it difficult to learn.

But your not here to learn English.

Select and Where

As you know, LINQ can be developed either using method or query syntax. If you didn’t know that, then read this Introduction to LINQ.

Lambda syntax is tricky to develop and maintain, so I don’t use it as often.

Query syntax is a darling of mine, since she is easy to read and manipulate so I always take advantage of her.

Wait, that didn’t come out right…

Before we dive into any examples, let’s have a look at the methods themselves for a moment.

Select(IEnumerable<T1>, Func<T1,T2>)

If you thought I was about to explain the parameters in detail, then you’re mistaken.

I like to keep things short and simple, which is a statement I often use to gaslight people from realizing that I don’t know what the hell I am talking about.

The Select Method maps your result into the shape you want it to assume.

When you append a .Select Method to a DataTable after it was enumerated (snipped into DataRows with our trusty .AsEnumerable), that collection of ICutItUpumerables is selected, and folded into colorful origami.

Only want the “Paid Column” from the DataTable in Array Format?

Dt.AsEnumerable.Select(Function(s) s(“Items”).ToString).ToArray

Select will “select” that mini-collection out for you and fold it up into an Array, List etc.

Programmers call it “Projection”.

I call it “Select”, because I like to keep it short and simple, so that I don’t forget about it 5 months down the line.

Where(IEnumerable<T1>, Func<T1, bool>)

If you thought I was about to explain the parameters in detail, then you haven’t paid attention to anything you’ve read for the past 4 minutes.

Too much social media has reduced your attention span to that of a goldfish’s. Yeah sure, go google how much that is, and you will forget what you were doing before that.

Where Were We Again?

Where takes in the same input, but it outputs a filtered result based on a Predicate.

If you’re scratching your head wondering what a predicate is, don’t worry.

It’s a function with a fancy name which tells us whether the items in our collection meets the condition we have provided inside the Lambda function. That result is translated into a set of Boolean values which is a series of “True” and “False” or ones and zeroes.

The predicate doesn’t give us the result though.

It is fed right back into our LINQ which then uses that reference to filter out the data we want.

Only want to retrieve those row items where the Status Column is “Due”?

Where can achieve that.

Only want to retrieve those row items where the Status Column is “Due”?

Where can achieve that as well.

Only want to retrieve those row items where the Gender Column contains “Men”?

Well, that’s pretty darn sexist.

Dt.AsEnumerable.Where(Function(w) w(“Items”).ToString.Contains(“Due”)).ToArray

This returns a filtered DataRow collection which contains the word “Due” in the “Items” column.

This works as well.

Dt.AsEnumerable.Where(Function(w) w(“Items”).ToString.Equals(“Due”)).ToArray

And both return a collection of DataRows, which can be directly converted to a DataTable.

Dt.AsEnumerable.Where(Function(w) w(“Items”).ToString.Equals(“Due”)).CopyToDataTable

Select performs projections, so we can’t directly convert the projection into a DataTable. That is when we use a combination of Where and Select Methods, or a Query syntax.

What If I Substitute It With Select?

Lets test that out and see what turns up.

An interesting result, isn’t it?

Wait, Wasn’t “Where” Tasked with Returning Boolean Values?

Remember what I said about the Select Method?

It returns a Projection.

When you add a condition, the Select Method “selects” the output of that condition, which is always Boolean.

Where on the other hand, uses the Boolean output to filter data from our IEnumerable, which is why when you provide a lambda function without any condition, it returns an error.

It won’t give out the Boolean.

Where can’t survive without his Tasty Boolean Snack. It consumes the Boolean, and processes data accordingly.

Where operates as a filter, while Select operates as a molding machine.

And that’s about it. Its nothing too complicated.

It only seems complicated because you haven’t had enough practice with it.

So go and practice!