为什么ReSharper不建议对这两个块都使用空传播？

debugcn 发表于 Dev

抽奖

ReSharper建议对“可损坏” if块使用空传播，但对于“ forceVelocityCalculator”则不建议。

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

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

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

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

我想念什么吗？我将对两个块都使用空传播。

特雷特尼

Unity提供了有关该主题的博客文章，但下面是简短摘要。

组件继承的Unity对象上的空传播是错误的。Resharper建议不要这样做，Visual Studio 2019会对此发出警告。

为什么会出现此建议IDamageable？因为它是一个界面。IDE（代码编辑器）不知道此接口的实例的类型。它不知道IDamageable继承自UnityEngine.Object，因此没有建议。ForceVelocityCalculator但是，继承自MonoBehaviour或ScriptableObject，两者都继承自UnityEngine.Object。这很重要，因为Unity已定制了==操作员。这样，您习惯的默认相等比较就不会发生。

博客文章给出了此决定的两个原因：

在编辑器中，Unity具有其自己的null概念。MonoBehaviour给a的未初始化字段提供了这个特定于Unity的空值。结合自定义==运算符，它可以使Unity在您开发时向开发人员提供其他信息。而不是接收NullReferenceException标准堆栈跟踪，而是接收增强的堆栈跟踪以及某些指示GameObject问题存在的指示。该博客文章提到了一个简洁的功能，该功能GameObject在“层次结构”窗格中突出显示了问题所在。
由于Unity是C / C ++引擎，并且您使用C＃编写脚本，因此您可以想到C＃对象可以“包装” C ++对象。有关该GameObject的所有信息（附加的组件，HideFlags等）都在C ++对象中。同样，这些C ++对象的生存期也得到明确管理。这就是为什么您使用Object.Destroy()而不是将事物设置为null的原因。定制==运算符解决了C ++对象已被破坏但“包装” C＃对象仍然存在的情况。在这种情况下，CSharpObject == null即使您的C＃对象在技术上不为null，也返回true。