Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,125 | Comments: 45,490

filter by tags archive


Peter Ritchie

How would you differentate between or conditions and and conditions?

Peter Ritchie

So, the And is implied... If you had to support both AND and OR conditions would you still do it that way?

Eric Hauser

The second one may be easier to read, but isn't it iterating over the collection twice?

Ayende Rahien

No, it isn't.

Evaluation it lazy, ater all.


+1 Ayende

Justin Rudd

It's cleaner, but there is a subtle issue. You have to remember that Where calls are applied in reverse order (last to first).

In the former code containment in "Items" is checked before the "Type" check. In the latter code, the checks are the same order (Where is applied from last to first), but it reads differently. In this particular case, it may not matter, but in something like this...

var nonNullNameOfLength10 = AllItems.Where(x.Name != null && x.Name.Length == 10);

It reads well...oddly (IMO).

AllItems.Where(x.Name.Length == 10).Where(x.Name != null);

I've seen people stack the Where calls in the same order as the conditions. And that causes the code to break (you could be checking the length of a null name).


Why not

var irems = AllItems

.Where(x=> x.Type == parent.Type)

.Where(x=> !parent.Items.Contains(x);

oops forgot last parens :)

var irems = AllItems

.Where(x=> x.Type == parent.Type)

.Where(x=> !parent.Items.Contains(x));
Duarte Nunes

@Justin Rudd

The calls are, indeed, applied in reverse order. But that means Where(x.Name != null)'s MoveNext() will call, before running its own code, Where(x.Name.Length == 10))'s MoveNext(), which could then throw a NullReferenceException. So, the code executes in the correct order (otherwise, as seen in your example, it would be really counterintuitive).

The only difference between Ayende's listings is that the latter, while much more readable, incurs one extra method call.


I'm guessing, readability.

Rik Hemsley

I would probably format this as:

var items = AllItems.Where



  x.Type == parent.Type


  ! parent.Items.Contains(x)


Yes, I use a lot of vertical space, probably too much...

BTW I've said it before, but SubText doesn't seem very good for a developer's blog where code is posted.

Rik Hemsley

Gah it screwed up the formatting... of course.

Benny Thomas

I like your thinking, Ayende!

Maybe you should make your own extension called And, that calls where, then it looks even better.


For me, first version is easier. I like the sound of "and" the && makes in my brain. But I would use in this case

.Where ( x => ( x.Type == parent.Type && !parent.Items.Contains(x)) )

I'm master of unnecessary parentheses.

Ben Hall

I don't agree, and I really don't think this adds much terms of readability.

Personally, I find the code much more difficult to read due to the fact that we are implying the operator being used . It also means that if we want to use a mixture of && and || in the code, we will have two different approaches or having to flip conditions which sound people could easily misread.

Given the two following examples, I would always bit the latter.

var items = AllItems

.Where(x=> x.Type == parent.Type)

.Where(x=> !parent.Items.Contains(x));

var items = AllItems

.Where(x=> x.Type == parent.Type && !parent.Items.Contains(x));

Peter Morris

I do something similar when I perform OCL queries


->select(givenName = 'Peter')

->select(familyName = 'Morris')

OR conditions need to be in their own select. I find it easier to read because a condition with lots of & needs to be mentally processed as a single element when reading the source, whereas multiple WHERE or ->SELECT can be read as smaller elements and I find them easier to read.

Ray Booysen

Based on the code below, you can see the where conditions are not done in reverse order:

Random r = new Random();

List <double values = new List <double();

for (int i =0; i < 10000; i++)




var result = values

.Where(d => { "Inner".Dump(); return true; })

.Where(d => { "Outer".Dump(); return true; });


Ray Booysen

And of course, this was done with LinqPad. ;)


@Ben Hall - I think the point you're missing is that the Ayende's version has less to read, less to think about.

I could understand it and re-read later, just as fast. The alternative you provided, always requires more time parsing in my brain.

I get a bit worried when people don't see this. I do believe that your brain would read it quicker as well.

I am starting to think that the only people who prefer that type of unnecessarily verbose sort of statement, these days, are those whose are allowing aspects of their personality influence what should be a more scientific choice.

Assuming we're all in the business of programming for "business" Ayende's choice has got to be the right one.

If you're programming something lower level, maybe I'll bend a little.


What reverse order are you guys talking about? Could you elaborate a bit?



Apart from readness, which for me second options creates more confusion, from my simple test it seems that these codes are not executing the same.

First is always evaluating the first statement, which is checking collection and that equality with parent.type is first true.

Second on the other hand applies filters as they are (hmm, it would be strange to apply pipeline in reverse order), and this is valid but with query expresions not operators. So if you would like to achive reverse execution you should write like this

var items = from x in AllItems

where x.type == parent.type

where parent.Items.Constains(x) == false

select x;



Sorry for confusion, it's to late :/, execution is the same of course with expressions/operators.

So still Ayende is it by mistake this order?


Comment preview

Comments have been closed on this topic.


  1. RavenDB 3.5 Whirlwind tour: I need to be free to explore my data - one day from now
  2. RavenDB 3.5 whirl wind tour: I'll have the 3+1 goodies to go, please - 4 days from now
  3. The design of RavenDB 4.0: Voron has a one track mind - 5 days from now
  4. RavenDB 3.5 whirl wind tour: Digging deep into the internals - 6 days from now
  5. The design of RavenDB 4.0: Separation of indexes and documents - 7 days from now

And 11 more posts are pending...

There are posts all the way to May 30, 2016


  1. The design of RavenDB 4.0 (14):
    05 May 2016 - Physically segregating collections
  2. RavenDB 3.5 whirl wind tour (14):
    04 May 2016 - I’ll find who is taking my I/O bandwidth and they SHALL pay
  3. Tasks for the new comer (2):
    15 Apr 2016 - Quartz.NET with RavenDB
  4. Code through the looking glass (5):
    18 Mar 2016 - And a linear search to rule them
  5. Find the bug (8):
    29 Feb 2016 - When you can't rely on your own identity
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats