[Low priority] Unity objects should not use coalescing assignment

[lcnvdl]

Hi! I think I found something that can be fixed easily :)

https://github.com/microsoft/Microsoft.Unity.Analyzers/blob/main/doc/UNT0023.md

UNT0023 Coalescing assignment on Unity objects
Unity overrides the null comparison operator for Unity objects, which is incompatible with coalescing assignment.

Examples of patterns that are flagged by this analyzer

using UnityEngine;

class Camera : MonoBehaviour
{
    public Transform a = null;
    public Transform b = null;

    public Transform NP()
    {
        return a ??= b;
    }
}

Solution

Use null comparison:

using UnityEngine;

class Camera : MonoBehaviour
{
    public Transform a = null;
    public Transform b = null;

    public Transform NP()
    {
        return a = a != null ? a : b;
    }
}

A code fix is offered for this diagnostic to automatically apply this change.

[lcnvdl]

You can check the pull request :)

[man572142]

Hi! Thank you so much for opening this issue and submitting a pull request. Null checks for Unity objects are definitely an interesting topic!

To keep it short: The way BroAudio handles these cases is actually quite safe. I chose this approach (or coding style) to make the experience between pure C# development and Unity development feel more consistent. Here are some of my personal thoughts on it.

I know the compiler suggests avoiding coalescing assignment (??=) in these situations. I also understand the risks of using coalescing assignment in Unity, but in many cases, I simply want to check whether a variable has been assigned a reference. Similarly, some Unity objects might never be explicitly destroyed via Destroy() method, or at the very least, they won’t be destroyed while they are still being referenced—like the AudioSource within AudioPlayer. Often, we’re primarily concerned with the reference itself rather than whether Unity still considers the object "alive."

Of course, Unity recommends using object.ReferenceEquals() in these situations, but that brings up the broader question of whether all these type of null checks should be changed to use it. Personally, I feel that Unity should provide something like: bool IsDestroyed() method rather than embedding this behavior into == operator, which changes how we perceive C# objects—then having the IDE remind us about it! 🤣 But I get that they have their own challenges. You can even see in this article that they struggled with this issue in the past.

For the coalescing assignments you pointed out, the situation where a reference still exists but the object has already been destroyed is highly unlikely. If such a case were to happen, it would indicate some incorrect handling that should be fixed immediately. In that case, we wouldn’t just check for xxx != null, we should also log an error or throw an exception, or else it would be difficult to track down the issue. That’s why, for me, using ??= and letting Unity throw a MissingReferenceException is actually better😊 it keeps the code cleaner, more readable, while also making debugging easier.

So unfortunately, I’ll have to close #21 , but I really appreciate your effort in bringing this up.🙏 If I’ve misunderstood anything or if there’s a flaw in my reasoning, I’d really appreciate your input! Thanks again!

[lcnvdl]

Hi! Thank you so much for opening this issue and submitting a pull request. Null checks for Unity objects are definitely an interesting topic!

To keep it short: The way BroAudio handles these cases is actually quite safe. I chose this approach (or coding style) to make the experience between pure C# development and Unity development feel more consistent. Here are some of my personal thoughts on it.

I know the compiler suggests avoiding coalescing assignment (??=) in these situations. I also understand the risks of using coalescing assignment in Unity, but in many cases, I simply want to check whether a variable has been assigned a reference. Similarly, some Unity objects might never be explicitly destroyed via Destroy() method, or at the very least, they won’t be destroyed while they are still being referenced—like the AudioSource within AudioPlayer. Often, we’re primarily concerned with the reference itself rather than whether Unity still considers the object "alive."

Of course, Unity recommends using object.ReferenceEquals() in these situations, but that brings up the broader question of whether all these type of null checks should be changed to use it. Personally, I feel that Unity should provide something like: bool IsDestroyed() method rather than embedding this behavior into == operator, which changes how we perceive C# objects—then having the IDE remind us about it! 🤣 But I get that they have their own challenges. You can even see in this article that they struggled with this issue in the past.

For the coalescing assignments you pointed out, the situation where a reference still exists but the object has already been destroyed is highly unlikely. If such a case were to happen, it would indicate some incorrect handling that should be fixed immediately. In that case, we wouldn’t just check for xxx != null, we should also log an error or throw an exception, or else it would be difficult to track down the issue. That’s why, for me, using ??= and letting Unity throw a MissingReferenceException is actually better😊 it keeps the code cleaner, more readable, while also making debugging easier.

So unfortunately, I’ll have to close #21 , but I really appreciate your effort in bringing this up.🙏 If I’ve misunderstood anything or if there’s a flaw in my reasoning, I’d really appreciate your input! Thanks again!

Hi!

Thank you for your response.

I read the article you shared, and what you said makes perfect sense.

This is also useful for the game I’m developing since it mentions performance, and I use it a lot for local caching in Lazy-type properties.

So, by using ?? and ?., we bypass this strange null check that Unity does with objects, achieving a performance improvement. Did I understand that correctly?

Thanks for the great insight!

Best regards!

[man572142]

You're absolutely right! This approach can indeed give you a slight performance advantage. However, the risks still exist, and consider the article is already 10 years old, it's worth questioning whether this performance gain is still significant enough to justify the risk on modern devices.

Personally, I’d recommend optimizing other areas that are more certain to yield improvements first. If you still need further performance boosts afterward, then it might be worth reconsidering this approach. Of course, if you're confident in it, it's still worth a shot.

Speaking of optimization, I highly recommend Unity’s new Project Auditor tool. It can analyze your entire project and pinpoint areas that need improvement, including code, resource management...etc. I used it myself and discovered some boxing, closure allocations, and certain Unity APIs with potential performance concerns that I hadn’t noticed before🤣 love it!