Difference between this.GetComponent() and gameObject.GetComponent()?

In a script attached to a game object, is there any difference between these three statements when getting the sprite renderer component? Do mySprite1, mySprite2 and mySprite3 refer to the same sprite renderer component? Any preferred way of getting the component?

Thanks !

Sprite mySprite1 = GetComponent<SpriteRenderer>();

Sprite mySprite2 = this.GetComponent<SpriteRenderer>();

Sprite mySprite3 = gameObject.GetComponent<SpriteRenderer>();
1 Like

No difference most of the time, so just use the first one unless you have a specific reason not to.

I only ever use the “this.” prefix when parameter names for a function can be ambiguous with class members (most common with things like “x”, “y”, “z”, “speed”, etc…). I used to add meaningless junk to the parameter names (like “newX”) but this makes the intellisense for the definitions sort of ugly. Within that function, the “this” will make it clear that you’re referring to the class variable, while leaving it off will refer to the parameter name (the closest scope match). You’ll have to be more careful if you’re intentionally using the same variable names on different scopes though, so the “newX” style approach might be better.

Specifying “gameObject” would likewise only really be useful when making a clear distinction I think, but I can’t recall a time when that distinction was actually necessary, unlike “this”…

2 Likes

Does ‘this’ refer to the object of the class in the script or the gameobject that the script is attached to?

Thank you so much!

“this” refers to the object of the class. When you inherit from MonoBehaviour you get a lot of functions from the Monobehaviour class. One of which is GetComponent, You also inherit Monobehavior’s gameObject variable. Now GameObject class also has a GetComponent, which is why it seems confusing.

this.GetComponent and GetComponent are the EXACT same thing.
gameObject.GetComponent is differnt (though logicaly it accomplishes the same thing and return the same thing)

On a side note regarding this. Another useful feature is if your writing a fairly complex function that uses local variables and data fields of the class. Now even if the names aren’t confusing, if everytime you modify or use one of the class’s variables you use: this.myVar = someLocalVar; it will be very obvious to a reader of that code when the variable he’s looking at is purely local in scope, or if its some global class data field. In c++ many people would accomplish this by always declaring Class variables m_someVar and local variables someVar.

“This” refers to the current instance of the current class, so it’s exactly the same as not using it at all (unless you need to explicitly reference a class member with name conflicts, as I mentioned).

For clarification, the first and second examples are exactly the same thing, just different ways of writing it out. Because the current class for a component is derived from MonoBehaviour, you have access to all of these members and functions: Unity - Scripting API: MonoBehaviour

The third example references the GameObject that the current class is attached to (essentially just a container for components, including this one), and it uses the GetComponent function which is identical to the GetComponent function for MonoBehaviours, so there’s no difference there, but the first/second and third examples are technically calling different functions, even if the results are exactly the same. When referencing the current GameObject, you have access to this list of members and functions instead: Unity - Scripting API: GameObject

1 Like

jinx!

1 Like

Thanks guys, your explanations are extremely instructional !

Much appreciated, especially for the time taken to pen them out.

Are there any performance differences between GetComponent() and gameObject.GetComponent()?

This thread is getting a bit old, but other than the “performance” issue of typing out a longer line of text, there’s probably a small cost to accessing the property :slight_smile:
I wouldn’t think about it too much, and just use ‘GetComponent’ if it’s on the same game object anyways.

1 Like

The gameObject.GetComponent() call is possibly a TINY bit faster- the difference in speed of having a single intermediate reference between PointA and PointB and completely negligible. This would be a seriously small micro-optimization and not worth any amount of effort at all, even just typing out a few extra characters, assuming there’s a difference at all.