0

Is there a good (technical) argument to use either one and not the other of the following ways to check if an instance is of a specific type? Is one of them error prone and should be avoided?

// Use "is".
bool isFolder = this.Parent is FolderEntity;

// Use "as".
bool isFolder = (this.Parent as FolderEntity) != null;

The intention of the code is to find out of the instance is a FolderEntity. In that case, the code will branch. The code is not interested in the resulting object.

From a point of clear code, I would use "is". What I was wondering however if there is a reason to prefer the "as" way of doing it.

Krumelur
  • 32,180
  • 27
  • 124
  • 263
  • possible duplicate of [Casting vs using the 'as' keyword in the CLR](http://stackoverflow.com/questions/496096/casting-vs-using-the-as-keyword-in-the-clr) – AndrewC Feb 24 '14 at 15:23
  • 1
    @AndrewC No it’s not. The question is not about casting at all. – poke Feb 24 '14 at 15:23
  • 1
    Related maybe: http://blogs.msdn.com/b/ericlippert/archive/2010/09/16/is-is-as-or-is-as-is.aspx – Soner Gönül Feb 24 '14 at 15:24
  • Technical arguments will not be important most of the time. Rather, look at the semantics - `is` is the way to go if you want to check the type. You're asking whether the instance is of a given type - how would `(x as e) != null` ever be better than `x is e`? – Luaan Feb 24 '14 at 15:25
  • 1
    `as` can only be used with reference/nullable types, `is` may be used with any type. – Jeff Mercado Feb 24 '14 at 15:26
  • 1
    to me; primarily opinion based as your question doesn't specify any details –  Feb 24 '14 at 15:26
  • @AndrewC the other question is about casting. – Krumelur Feb 24 '14 at 15:27
  • 1
    The second snippet is behind [the door on the right](http://i0.wp.com/s167866.gridserver.com/wp-content/uploads/2009/02/wtf.png?resize=474%2C373). Enough reason. – Hans Passant Feb 24 '14 at 15:28
  • @Krumelur what are you looking to do if it is a certain type? Didn't put enough detail in the question, as I'm sure the answer will vary. :) – AndrewC Feb 24 '14 at 15:28
  • @AndrewC Tried to make it a bit clearer. But it seems like this is really something that is primarily opinion based - which answers my question :-) – Krumelur Feb 24 '14 at 15:33

2 Answers2

4

If you are only interested if something is of a certain type, and you don’t need that object as an object of that type, then just use is. That way, you clearly convey your intention to check its type, and not to cast it into another type which would be a completely different intention.

That is regardless of its actual implementation, where both are somewhat implemented with each other.

But implementation detail is rarely important (and micro-optimization is more harmful), when you can choose to write something in clear way to match your intent.


As you said yourself, “the code is not interested in the resulting object”, so you don’t need to cast it into another type; you just need to check its type: So yes, let the code be clear about that and just use is.

If, on the other hand, you would want to check its type but then also do something with it, you would do it like this:

FolderEntity folder = this.Parent as FolderEntity;
if (folder != null)
    DoThingsWith(folder);
else
    DoThingsWithoutTheParent();
poke
  • 369,085
  • 72
  • 557
  • 602
2

The is operator in C# is used to check the object type and it returns a bool value: true if the object is the same type and false if not.

For null objects, it returns false.

The as operator does the same job of is operator but the difference is instead of bool, it returns the object if they are compatible to that type, else it returns null.

In the case of is operator, to type cast, we need to do two steps:

  1. Check the Type using is
  2. If it’s true then Type cast

Actually this affects the performance since each and every time the CLR will walk the inheritance hierarchy, checking each base type against the specified type. To avoid this, use as it will do it in one step. Only for checking the type should we use the is operator.

Anurag Jain
  • 1,371
  • 4
  • 23
  • 34