Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Why does ReSharper not suggest using null propagation for both of these blocks?

ReSharper suggests using null propagation for the "damageable" if block, but for the "forceVelocityCalculator" one there is no suggestion.

void Damage(Collider hitCollider)
{
    var damageable = hitCollider.GetComponent<IDamageable>();

    if (damageable != null)
    {
        damageable.TakeDamage(_damage);
    }
}

void Push(Collider hitCollider)
{
    var forceVelocityCalculator = hitCollider.GetComponent<ForceVelocityCalculator>();

    if (forceVelocityCalculator != null)
    {
        forceVelocityCalculator.Push(_pushForce, GameAPI.playerTransform.transform.forward);
    }
}

Am I missing something? I would use null propagation for both blocks.

like image 885
Drawgo Avatar asked Oct 21 '19 13:10

Drawgo


People also ask

Why should Unity objects not use null propagation?

Object is destroyed, even if the object itself isn't actually null. Null propagation cannot be overridden in this way, and therefore behaves inconsistently with the == operator, because it checks for null in a different way.

What is null propagation?

Starting from version 6.0, C# supports a shorter notation, the null conditional operator. It allows checking one or more expressions for null in a call chain, which is called null propagation. Such a notation can be written in a single line whereas a number of if-else statements typically occupy many lines.


1 Answers

Unity offers a blog post about this topic, but a short summary follows.

Null propagation on Unity objects, which your components inherit from, is incorrect. Resharper doesn't suggest doing it and Visual Studio 2019 gives a warning about it.

Why does the suggestion occur for IDamageable? Because it's an interface. The IDE(code editor) doesn't know the type for an instance of this interface. It can't know that IDamageable inherits from UnityEngine.Object, so no suggestion occurs. ForceVelocityCalculator, however, inherits from MonoBehaviour or ScriptableObject, both of which inherit from UnityEngine.Object. This is significant because Unity has customized the == operator. In this way, the default equality comparison you're used to is not what happens.

The blog post gives two reasons for this decision:

  1. Within the Editor, Unity has its own concept of null. Uninitialized fields of a MonoBehaviour are given this Unity-specific null value. This, combined with a custom == operator, lets Unity provide additional information to you, the developer, while you develop. Instead of receiving a NullReferenceException and standard stack trace, you instead receive an enhanced stack trace plus some indication of which GameObject the problem exists for. The blog posts mentions a neat feature where they highlight the problematic GameObject within the Hierarchy pane.

  2. Since Unity is a C/C++ engine and you write scripts in C#, you can think of your C# objects "wrapping" the C++ objects. All of the information about that GameObject (attached components, HideFlags, etc) are in the C++ object. Also, the lifetime of these C++ objects is explicitly managed. It is why you use Object.Destroy() instead of setting things to null. The custom == operator solves the scenario where a C++ object has been destroyed but the "wrapping" C# object still lives. In this case, CSharpObject == null returns true, even though your C# object technically is not null.

like image 184
ChoopTwisk Avatar answered Nov 14 '22 23:11

ChoopTwisk