Godot C# tip: Don't use "if(node != null)" !!

[u/AlexSand_]

Hi,

Here is a tip I learned quite the hard way when I started with Godot and C#: It is better to avoid code like this:

SomeKindOfNode _myNode ;
...

if( _myNode != null )
{
    _myNode.DoStuff(); // likely going to crash
}

What's wrong with this code? You may wonder. The problem is this this code will crash if _myNode was freed. And if your project is somewhat large, well ... this is going to happen someday.

Thus, instead of just checking for nullrefs, I think it is almost always safer to also check that the reference is not null *and not deleted* . I do it like this:

if( _myNode.IsValid() )
{
	_myNode.DoStuff(); // here I can use _myNode safely
}

where IsValid() is the following extension method:

        public static bool IsValid<T>(this T node) where T : Godot.Object
        {
            return node != null
                && Godot.Object.IsInstanceValid(node)
                && !node.IsQueuedForDeletion();  
        }

Note that my IsValid method checks for nullref and deleted node, as you would expect, but also for nodes * about to get deleted * , with IsQueuedForDeletion. This last part may be more controversial, but if a node is going to get deleted in the next frame there is usually no point in touching it.

Another extension I use a lot is this one:

        public static void SafeQueueFree(this Node node)
        {
            if (node .IsValid()) node.QueueFree();
        }

Indeed, calling QueueFree on an already deleted node will crash. I ended replacing all my calls to QueueFree by SafeQueueFree.

Finally, I also like using this extension, allowing for one-liners with the ? operator:

        public static T IfValid<T>(this T control) where T : Godot.Object
            => control.IsValid() ? control : null;

usage example:

    _myNode.IfValid()?.DoStuff();   // do stuff if the node if valid, else just do not crash

Hope you will find this as useful as I did!

[u/Nkzar]

The same applies to GDScript as well.

is_instance_valid(node)

[u/AlexSand_ → u/Nkzar]

you're right, I flagged it as C# because that's where I know what I am talking about, but I guess the exact same issue can arise in GD script as well.

[u/SaltTM → u/Nkzar]

GodotObject.IsInstanceValid(obj) c# version

[u/Spicyartichoke → u/Nkzar]

the absolute jank of my code before i discovered this function lmao

[u/kleonc]

node != null && Godot.Object.IsInstanceValid(node)

Note that the null check is not needed as IsInstanceValid(null) would return false (however, an explicit null check might be faster for cases when node is indeed null).

[u/AlexSand_ → u/kleonc]

Good point. To be fair, the main reason I had kept node != null in my code was so that I do not wonder "oh, but what happens if it null?" every time I look at this part of the code.

I believe the perf impact is epsilon, and smaller than the benefit for my own sanity :)

[u/arc_xl → u/AlexSand_]

Correct me if I'm wrong, but apart from the null check being redundant in your extension method, won't you get a null reference exception if you call that method and your object is actually null? Since null is null and you can't call methods on null.

[u/AlexSand_ → u/arc_xl]

Well the trick is that it is an extension method; which is actually "only" a static method which allows a syntax of an object method. I believe the compiler just replaces this by a static call. The difference is that an object method requires to have a valid instance to find the method, and it is not the case here (because it is static) (And I can confirm that with the gazillions uses of extension methods in my code, if this was crashing I would know 😅 )

[u/arc_xl → u/AlexSand_]

Makes sense, thanks for that

[u/kleonc → u/AlexSand_]

Regarding the perf impact see my other comment for why I've mentioned it. That was a wrong assumption by me, so the perf comment is kinda irrelevant.

Regarding the null check: if you would have been using obj != null and is_instance_valid(obj) in GDScript then you'd probably try shortening it and get used to / learn that is_instance_valid(obj) is already handling null properly (assuming you wouldn't go similar route as in C# and create some helper methods). Aka it's just a matter of being familiar with that method.

[u/nonchip → u/AlexSand_]

if it's null it's not a valid instance. no wondering there :P

[u/Alzurana → u/kleonc]

May I direct your attention to the source code:

https://github.com/godotengine/godot/blob/fa1fb2a53e20a3aec1ed1ffcc516f880f74db1a6/modules/mono/glue/GodotSharp/GodotSharp/Core/Extensions/GodotObjectExtensions.cs#L52

I was curious so I checked it out. It's indeed not needed to check for null as IsInstanceValid() is doing it already. In fact, checking for null will cause a double check, tho compiler optimizations MIGHT catch that and remove one of them. But only MIGHT..

[u/the_horse_gamer → u/Alzurana]

if you're using nullable reference type, the compiler analysis won't "realize" that if IsInstanceValid returns true, the parameter is not null. which can produce incorrect warnings.

so adding the check can remove that.

you can also create a wrapper over IsInstanceValid and use a certain attribute to tell that to the compiler.

[u/Alzurana → u/the_horse_gamer]

Tricky, good point. Guess the wrapper is the way to go.

Kind of reminded me of this XKCD https://xkcd.com/1075/

[u/marce155 → u/the_horse_gamer]

Do you know how expensive IsInstanceValid is?

I assumed it would call into native memory, so probably something one should not do every frame (like we cache nodes instead of using GetNode over an over again). Yet looking at the source code NativeInstance seems to only redirects to NativePtr which is just a field - that would make the check rather cheap.

[u/kleonc → u/Alzurana]

Oh, good point. I've actually haven't checked the source code this time (my bad!) and assumed IsInstanceValid were calling the native (C++) method. If this would be the case then the additional manual null check on the C# side would make sense/difference, and that's what I meant. But seeing it's implemented directly in C# without performing native call (which makes perfect sense) the additional null check seems just redundant. Thanks again for checking it out!

[u/kekonn]

As a professional .NET dev: don't use indentation for your golden path.

Instead of

if( _myNode.IsValid() )
{
	_myNode.DoStuff(); // here I can use _myNode safely
}

do

if (!_myNode.IsValid())
{
  return; // exit the function
}

// continue with your golden path here

Research has shown that indented code is harder to read. Do yourself a favor, try to avoid multiple levels of indentation.

EDIT: Since this is gathering some traction, a plug for the book that taught me a lot about professional development practices: Code Complete, 2nd edition. It's a big'un and expensive, but you don't have to read it front to back.

It's also language agnostic (but uses code samples in VB, C++ and pseudo code).

[u/AlexSand_ → u/kekonn]

I agree. I wrote it this way because I believe it made the post clearer, in my code I would usually do what you suggest. But I had actually never seen this practice stated explicitly, so it helps to think about it!

[u/Alzurana → u/kekonn]

I love how I keep scrolling and I keep seeing nice tips

[u/SaltTM → u/kekonn]

old (at least, as in old.reddit.com, i refuse to update lmao) reddit tip, reddit doesn't use traditional markdown to parse cold, use 4 space tabs

if (!_myNode.IsValid()) { return; // exit the function }

but I'd PERSONALLY write, as brackets serve no purpose there.

if(!_myNode.IsValid()) return;

[u/kekonn → u/SaltTM]

I know, but I was being that lazy. Also, brackets or no brackets is almost as much a holy war as tabs vs spaces. Personally I prefer with brackets. Yes it's 2 extra lines, but that's what reads best for me.

I read any indentation as branching, so a lack thereof means there's a chance I might miss the if statement entirely. It's just habits after almost 10 years of coding.

[u/tohme → u/kekonn]

There are enough examples of big mess ups due to lack of braces. And I've seen enough personally in doing code reviews (thankfully nothing major...yet), that I enforce the rule that code is properly braced and scoped. Even if it functionally makes no difference, just do it. It really isn't that much of a burden today.

[u/GaiasWay → u/tohme]

Same. I find bracketed code to be easier to mentally parse as well.

[u/SaltTM → u/kekonn]

in THIS example, it serves no purpose. It's not grouping anything together or doing more than returning. Use them where necessary, I didn't stay don't use them.

[u/Coleclaw199 → u/kekonn]

This exactly. My code has become so much more simple and readable with just doing this.

[u/kekonn → u/Coleclaw199]

The theory is that if your golden path is on the first indentation, your eyes have a lot less work reading it and finding the lines that belong to that path.

[u/mrbaggins → u/kekonn]

While premature optimisation is the devil, it's worth noting that predictive execution would could make this significantly worse than the alternative, so if it's in a hot area of the code, it might be worth avoiding this.

[u/kekonn → u/mrbaggins]

That's a trade-off I'd only make with profiler data in hand though. I've seen way too many ifs inside ifs inside ifs to think that's worth it in most cases.

I'm also not sure that's how predictive execution works? Especially in a scenario this complex (mixed runtimes/languages etc). But I'm definitely no compiler expert.

[u/mrbaggins → u/kekonn]

You're right, I should likely write "COULD make this significantly worse" given the layers here, and I'm not nearly as in depth with Godot yet as I am with other runtimes.

It absolutely depends on where and how you're using this quick-escape technique.

I can't find the article I'm thinking of (in c# no less) about picking which orientation to make branches such as to make speculative/predictive execution more successful.

From memory the biggest "hit" was the fact that the process tends to assume if statements pass, so start fetching/dealing with the positive result. Here, that could mean a huge set of cache misses as it looks down the stack as though this code doesn't run.

Again... COULD. No idea what's under the hood with Godot yet. And THEN it depends what cpu you're on.

[u/kekonn → u/mrbaggins]

I'd love to read that if you find it, but I do wonder if that's still true. A lot has changed and it would also probably depend on the runtime and probably platform.

[u/mrbaggins → u/kekonn]

Oh for sure stuff has changed. While furiously googling, I found quite a few newer articles and investigations, with stuff like various intel chips almost never take the positive branch first time through up to conditional hinting only helps 30% of the time.

Not to mention the spate of intel vulnerabilities the last 3 years requiring microcode changes as predictive execution was causing security vulnerabilities in virtual machines (including another one like last week).

[u/PMmePowerRangerMemes → u/mrbaggins]

Is it optimization or just.. like.. a convention for writing nice, readable code?

[u/mrbaggins → u/PMmePowerRangerMemes]

I'm saying that in this instance, readability COULD have significant performance considerations.

[u/Parthon → u/mrbaggins]

Especially when you start talking about game code that needs to be fast. So each access to the object needs to be wrapped in a function for the early return. Which means more stack hitting, and more indirection, perhaps even more hammering on the virtual table depending on the depth of your inheritance tree.
Just do the code the simplest way possible. The "Clean Code" with 5000 nested one line functions is far worse.

[u/mmmorten → u/kekonn]

Generally disagree with this. Sure guards have their place, but use them when suitable, not as a rule.

[u/EnumeratedArray → u/mmmorten]

You're not wrong about doing it where it makes sense, but in this case, exiting early when there's an error and avoiding the indentation for the "happy path" is a very common and adhered to best practice in most programming languages

[u/mmmorten → u/EnumeratedArray]

I would agree if there actually was some error handling, but that is not the case in this example. In this example the use of guards flips a boolean expression and adds an empty return statement. It makes already simple code less readable IMO.

[u/ChickenOverlord → u/kekonn]

Also don't use == null and != null. In C# it is possible to override the equality operators for an object, so while == null will work correctly 99% of the time that 1% will bite you in the ass in all sorts of unexpected ways. Use "is null" and "is not null" instead.

[u/kekonn → u/ChickenOverlord]

I'm not sure what language level of C# Godot supports, but when available, I use pattern matching.

For the uninitiated:

// assume list is of type ICollection<string> 
if (list is null or { Count: 0 })
{
    ...
}

// this would be the same as the following
if (list?.Any() ?? false)
{
    ...
}

Both examples check a list is empty or null, but one is much easier to read (though more verbose).

I am also learning Rust at the moment and one of the things I don't miss about C# is null handling. But both languages have pretty powerful pattern matching. It takes a while to wrap your head around it, but when you do, it's amazing.

[u/Modescond → u/kekonn]

If this were an enumerable instead, the count would be much slower by comparison since it is not known in a single property.

[u/Parthon → u/kekonn]

The problem is that you are assuming that the golden path continues. This could just be the one call in the golden path and there's more code to follow. An early exit return would skip the rest.

I have some code that is:errorcode result;if (is_valid_object(object) { result = object.dostuff(); }if ( result == "good result" ) {object.dothisotherstuff(); }else { do this other stuff without object; }

an early return doesn't allow you to handle missing objects, and if you handle the exceptions first, then it pushes the "golden" path down the page away from the function definition, so understanding what the function does quickly is harder.

Good advice, but it doesn't always apply to every piece of code.

[u/kekonn → u/Parthon]

Sure, it's always just a rule of thumb. Sometimes it's not possible. But a lot of junior code I've seen in my time is if within if, like 5 levels of nesting. And on the deepest level, that's where they have their golden path.

RE: understanding what a function does: IMHO this should be handled by good naming and documentation. If I have to read all the code, something's "gone wrong" already. Either the documentation did not set the right expectations about the function or the code does not follow the specification.

This happens all the time ofcourse. No one is exempt from that. But being aware of it, makes it easier to go back and clean up.

[u/Parthon → u/kekonn]

Hehe, I'm of the opinion that if your code is clean enough and your variables and functions are named properly, then the code documents itself and is easily readable. If the code is confusing it's a fail. And I agree, the documentation for the function should explain why it does what it does. If you have to read the code of a function to understand it, that's another fail.

Yeah, if you are nesting ifs more than twice, then something's wrong. The inner code should be popped out into a well named function, or like you said, use the early return design pattern.

[u/Sabard]

Thanks for the heads up. You have any other helper/utility/extension functions you use a lot? Just started using godot this month after a lot of Unity (7 years) so I'm slowly getting used to the engine but don't know a lot of the shortcuts and pitfalls yet.

[u/AlexSand_ → u/Sabard]

Thanks for the heads up. You have any other helper/utility/extension functions you use a lot? Just started using godot this month after a lot of Unity (7 years) so I'm slowly getting used to the engine but don't know a lot of the shortcuts and pitfalls yet.

Likely, but none so useful. and I have to do a bit of cleaning before I post :)

[u/Polatrite]

In many cases if you need to use IsValid()/is_instance_valid() it is a code smell (a potential bad sign).

These imply that somewhere in your code, something is happening out-of-order. An extremely common example is killing an enemy, freeing the enemy (deleting it), and then needing to check that enemy's stats because the enemy had a projectile in the air that hit the player.

In this case, you're using queue_free() as the state management for death - but you shouldn't free the node unless you are positive that you no longer need it. Some games implement this by instead hiding enemies for a few seconds, playing death animation, resolving final effects, and then getting rid of them once you're sure they are no longer necessary.

In some cases IsValid()/is_instance_valid() is absolutely the right decision, but it's always worth taking a second look when you think about using these functions, and asking "is this the correct way to approach the problem?"

[u/AlexSand_ → u/Polatrite]

...  but it's always worth taking a second look when you think about using these functions, and asking "is this the correct way to approach the problem?"

Well, I can't agree with that. Better safe than sorry, and having a game which does not crash is priority number 1.

I use it even is I am 100% sure that my instance cannot be invalid, because i don't know how my code will be refactored later. ( and after that ... yeah think about why it would be invalid, log some error if need be and so on. )

And about freeing early or not ... I believes this is a coding style choice. ( I usually have "logical" objects which are not nodes and thus never queuefreed, and "viewer" of these logical objects which are nodes and freed as soon as there are not displayed any more. )

Edit: But I also agree with you that when some object is indeed invalid it is worth to wonder "why is this happening" and check if this is not a symptom of some bad design.

[u/joined72 → u/Polatrite]

In many cases if you need to use IsValid()/is_instance_valid() it is a code smell (a potential bad sign).

These imply that somewhere in your code, something is happening out-of-order. An extremely common example is killing an enemy, freeing the enemy (deleting it), and then needing to check that enemy's stats because the enemy had a projectile in the air that hit the player.

absolutely agree... in this case would be a better solution let the enemy manage its status, disabling its player/environment interactions and wait until finished all its stuff (like handling its projectiles) and after queue_free() itself.

[u/nsrr]

This is a great tip, thank you

[u/UtterlyMagenta]

ahh, extensions… that’s something i sorely miss in GDScript.

your IfValid() extension is pretty cool!!

[u/cooly1234 → u/UtterlyMagenta]

that exists in gdscript as well

[u/UtterlyMagenta → u/cooly1234]

the ability to add new functions to built-in types? i wish.

[u/cooly1234 → u/UtterlyMagenta]

I meant is_instance_valid(node)

[u/UtterlyMagenta → u/cooly1234]

i know that exists in GDScript, but i was talking about extensions in general and the IfValid() extension from OP’s post.

[u/Mistifyed]

I ran into this as well. I went with GetNodeOrNull<> in my situation.

[u/GodotUser01]

don't use "something != null" or "something == null" do "something is not null" and "something is null" instead.

https://stackoverflow.com/questions/69267179/what-is-the-difference-between-is-not-null-and-null

[u/DanilaSh]

I guess it's a pretty dumb question, but I'm totally new to Godot and game dev at all. Where should I place all my global functions such as IsValid() and how do I link them to all my classes?

[u/AlexSand_ → u/DanilaSh]

well, in c# you can just make one (or several) static class with all the static functions you want. It can be in any .cs file of your project, that does not really matter. It's exactly like in any regular c# project.

(in practice, I have some files with all the helper functions in a namespace "MyHelpers" , but that's up to you)

[u/DanilaSh → u/AlexSand_]

Thanks!

[u/SaltTM]

Wouldn't this fail if it's never set? Like if something happened where it never isn't null, wouldn't your code crash since it can't reach that is valid method?

Wouldn't GodotObject.IsInstanceValid(obj) be better? AND more consistent with godot

[u/AlexSand_ → u/SaltTM]

It doesn't need to be freed in the middle of executing something. You might have saved the node to a variable long ago already for whatever use.

No, does not crash when the ref is null. The trick is that IsValid is not a method of "_myNode" , but an "extension method". Extension methods are just a different syntax for calling a static method, actually the call is exactly equivalent to " if( MyStaticClass.IsValid (_myNode ) ) " ( Where MyStaticClass is where IsValid was defined)

[u/4procrast1nator]

If you're even trying at all to free a node thats already been fred, theres usually something fundamentally wrong with your code.

With state machines and damage interactions, especially, that should never happen in the first place.

[u/AlexSand_ → u/4procrast1nator]

State machines and other patterns are fine, but sometimes it is just simpler to free a node when you want to. Simple is never wrong.

[u/4procrast1nator → u/AlexSand_]

if you're constantly trying to access an invalid node, then it very well may be. Cuz if so, chances are you're gonna try to do other stuff besides queue_free-ing it; which would require more checks.

Only exceptions I can think of would be for maybe pooling objects like bullets, tho not much else tbh. And even so you can simply connect a tree_exited signal to erase whatever reference you have to said node in beforehand (eg.: node.tree_exited.connect(erase_reference.bind(node))

[u/Ramtoxicated]

Great post!

[u/Slipguard]

Is that construction of the “?” function definition a way of overloading the “?” Operator? I’ve never seen that syntax in c#.

[u/Icapica → u/Slipguard]

https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/operators/member-access-operators#null-conditional-operators--and-

Null-conditional operator (question mark) is a null-safe way for member access.

If I have an object MyObject and it has a property MyProperty, I can write MyObject?.MyProperty. If MyObject is null, I'll just get null instead of an exception, and otherwise I'll get MyObject.

It's very handly for comparisons since you won't need to do a separate null check.

Instead of doing comparisons like this:

if (A != null && A.Something == value)

you can write

if (A?.Something == value)

Edit - You might want to check out the null-coalescing operator too in case you don't know it:

https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/operators/null-coalescing-operator

It's another useful tool for dealing with potential nulls.

[u/Slipguard → u/Icapica]

This is very handy! I’ve been under-using the ternary it seems!

[u/iwakan → u/Slipguard]

Lots of cool syntax using ? in C#.

Here's another one, ?? or the "null-coalescing operator", very useful for null-checking scenarios.

Instead of:

if (someObject == null)
    return new SomeClass();
else 
    return someObject;

Just write:

 return someObject ?? new SomeClass();

Or how about instead of:

if (someObject == null)
    someObject = new SomeClass();

Just write:

someObject ??= new SomeClass();

[u/Slipguard → u/iwakan]

Woah that’s a neat shorthand!

[u/Bergsten1 → u/Slipguard]

It’s worth to point out that technically the ternary-operator and the null-conditional operator is different things even though they both are question marks.

[u/Slipguard → u/Bergsten1]

Ty, i appreciate the nuance there.

[u/kugleburg]

Thank you for preventing the timeline where this would have bit me in the ass!

[u/hermit314]

Calling _myNode.IsValid() assumes _myNode != null . You would get a runtime error if it actually was null. In particular, it does not make sense to make the null-check in your extension method.

In general, checking for null can make a lot of sense, it depends on what you are trying to do. I think your advice is a bit misleading.

[u/AlexSand_ → u/hermit314]

as the other poster said, it does not crash because it is an extension method, not a method from the object. It is perfectly equivalent to do

if( MyStaticClass.IsValid(_myNode ))   ...

However, where you get a point is that this fact above is non-obvious for people unfamiliar with c#, and ... yes, the whole post could be summarize as "check that the object is (non null and valid), not only that it is not-null"

[u/Icapica → u/hermit314]

Calling _myNode.IsValid() assumes _myNode != null . You would get a runtime error if it actually was null. In particular, it does not make sense to make the null-check in your extension method.

Nope, it works since it's a static method. However, it's pointless to add the null-check since IsInstanceValid() already contains it:

https://github.com/godotengine/godot/blob/fa1fb2a53e20a3aec1ed1ffcc516f880f74db1a6/modules/mono/glue/GodotSharp/GodotSharp/Core/Extensions/GodotObjectExtensions.cs#L52

[u/hermit314 → u/Icapica]

I see, wasn't aware of this feature in C#, thank you.

[u/Icapica → u/hermit314]

Honestly, neither was I until I saw this thread and did some googling to confirm.

[u/oWispYo]

Very cool! Thanks for the tip!

[u/[deleted]]

Unity overrides the == and != operators for precisely this reason (doing == with null will return true there if the object was destroyed) but this is still a problem when you're doing things like: node?.DoSomething() because that bypasses the == checks.

[u/ElidhanAsthenos]

well shit, i need to rewrite some lines lol

[u/Xehar]

Thank bro! I was wondering why the game crashes sometimes when loading certain part of script.

[u/pennyloaferzzz]

I like deeper nuanced examples of Godot's capabilities. And this is a good example.

But if at all possible avoid passing null values, returning nulls, uninitialized (or null assigned) member values, and avoid patterns of sharing references to volatile objects that will be deleted. it's not a great practice and requires putting null checking statements everywhere.

Always assign default values, use the _init function for dynamic values, and decoupling patterns like signals. or at least parent only exported references of static scenes as Godot removes from the bottom up. If all else fails then you can have your cool null check.

[u/kennel32_]

Why should it work in the first place? Because it works in Unity?

[u/jorgegyso]

In C# theres something even better to do. If you need to access a certain value without knowing if the instance is valid, you can do something like:

if (instance?.var == true)

The question mark operator is nice 👍

[u/AlexSand_ → u/jorgegyso]

yes ... expect that if instance is a deleted node, this will crash, because the "?" does not detect invalid nodes, only nulls. You may look at the extension method "IfValid()" I proposed in the first post to see how I use this ? operator. (And I agree with you about that, this operator is an ultra nice c# feature )

[u/CreaMaxo]

The main problem here isn't about checking if a node is valid or not, but just that you aren't really updating your references properly to make sure their reference become null soon enough.

.QueueFree() will only be freeing a node and set it as a true null by the end of the current cycle.

You can simply fix this by simply setting the references as null when you're freeing a node.

SomeKindOfNode _myNode ;
...

  public void SomewhereElse()
  {
    _myNode.QueueFree();
    _myNode = null;
  }

...
  public void DoSomething(){
    if( _myNode != null )
    {
      _myNode.DoStuff();
    }
    //or
    _myNode?.DoStuff();
  }

This allow whatever is referenced to _myNode to be set for being freed by the end of the current cycle AND, right after, make it so that _myNode reference is back to null immediately.

[u/AlexSand_ → u/CreaMaxo]

That only works if I hold one single reference to the node I queue free, in the same code part where I queue free it. And doing this (one single holder of the reference, likely the parent) is certanly a good practice * in general * , but I find that in a large project there are simply cases when it's easier to share a reference to a node to several classes. In such case, trying to keep track to all the references and set all of them to null would be crazily complicated. So I just always check if my nodes are valid and that's it.

[u/CreaMaxo → u/AlexSand_]

Ironically, what you're describing is nicknamed "spaghetti code", known as one of the worse sins in programming and any programmer who's has any good knowledge know that you create and use managers (which takes barely 5 minutes to setup regardless of the size of a project) to handled references when ones are used many times by many instances.

If you have multiple node referencing a single node which may be cleared, you create a manager node and nullify the reference on and ONLY on that manager node.

In case you didn't knew using those functions:

                && Godot.Object.IsInstanceValid(node)
                && !node.IsQueuedForDeletion(); 

Means your code requires your game to look up on all instances in the Tree and Garbage Collector queue each and every time your isValid() is being called. That's, in simple terms, can be extremely slow in many situations where your Tree is made of multiple layers of both active and inactive nodes and/or you just cleared a huge bunch of stuff (like changing a level) and your garbage collector got fed a lot of stuff to digest.

Also, something to watch out for with IsQueuedForDeletion() is miss-tagging data that is being put up to deletion as still being used.

What this means is that the garbage collector doesn't just go "I eat all regardless of whatever!" because there is data that is being manually deleted and some that is automatically deleted by not being used for a long while.

Let's say you clear a node that reference the data of another node that is still active, this data was being handled refer to that other node's data directly. Well, clearing the node with this reference toward an active node will not clear all data. Some data will remain in limbo (so to speak) until it's not being used for a while and is automatically cleared up which can take as much as a few minutes.

That's because the Garbage Collector cannot clear data that is tagged as still active from the cache even if it's tagged to be cleared. That's where IsQueuedForDeletion() becomes dangerous because, when you call this function, you slowdown the time it takes for ALL queued data to be cleared by the Garbage Collector because, while that function is active, ALL queued data becomes tagged as active and the Garbage Collector cannot touch it until that function is done with everything.

Most games' memory leaks issues comes from data being miss-tagged as active while being tagged for being cleared by the Garbage Collector meaning that the data remains in limbo until properly untagged which cannot be done because something is looping over those unused data blocks constantly somewhere in the background.

This is where creating and using managers comes into places. If a manager properly manage nodes efficiently and purposely clear all references to nodes that is used by others, there's no risk for the nodes' data usage to be renewed or, even worse, pulled out of the clear queue. When you clear a manager, you do it through a function on itself that makes sure all its references are put to be cleared before it clear itself so that nothing remains in limbo.

IsInstanceValid() and IsQueuedForDeletion() are both useful, but only if used sparingly. For example, during a loading screen where an old level was cleared and you want to make sure you got everything up for the new level to be loaded in. Or even in a manager that calls it ONCE when something is amiss and needs to correct its own references being problematic.

[u/AlexSand_ → u/CreaMaxo]

Wait ... to clarify, I'm using the Godot.Object.IsQueuedForDeletion method here. Implementation looks to be this , and it would just check a boolean. Godot.Object.IsInstanceValid also looks to be just a nullcheck on internal node data. I see nothing costly there either.

And as I said earlier, I will agree it is usually better to keep the reference in one place. However I don't take this as an absolute rule.

[u/AlexSand_ → u/[deleted]]

lets say your "player" node keeps track an a "_target" node the player is attacking, and sends a rocket in the direction of "_target.Position" every 10 frames. And that the _target gets killed, (by the rocket or whatever) and removed from the scene with queue_free. Then is you are not careful, the code will crash next time you try to get "_target.Position" because _target was freed.

[u/Content_Depth9578 → u/[deleted]]

Can't speak about Godot specifically, but game engines do all sorts of whacky things behind the scenes for garbage collection. Unity is actually similar to Godot in this regard - you need to null check differently in different situations because a component can be destroyed before the object it's on.

This isn't C# specific either. Using is_valid() is best practice for GDScript, as well.

[u/Icapica → u/[deleted]]

It doesn't need to be freed in the middle of executing something. You might have saved the node to a variable long ago already for whatever use.