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.
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.
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.
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:
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With