Nullable reference types в Unity простыми словами

С выходом Unity 2021 LTS в полной степени стал доступен Nullable reference types. Коротко расскажу о том, как включить поддержку Nullables в Unity, и с какими проблемами вы можете встретиться.

Коротко о Nullable reference types

Если вы уже знакомы с данной концепцией, то можете сразу перейти к разделу “Как включить Null reference type в проекте Unity”.

Nullable reference types позволяет четко определять какие переменные ссылочного типа могут принимать значения null, а какие — нет. И еще на стадии написания кода находить уязвимые места, которые могу приводить Null reference exception.

public class Person    
{
    private string _name;
    private string? _occupation;
}

В этом примере переменная поле _name всегда должна иметь значение. В свою очередь для _occupation допускается значение null. Уже в этом примере возникнет предупреждение, с указанием на то, что объект Person может быть создан с пустым полем _name. Действительно, при таком раскладе _name обязательно должен заполняться в конструкторе.

public class Person    
{
    private string _name;
    private string? _occupation;

    public Person(string name)
    {
        _name = name;
    }
}

Или даже так.

public class Person    
{
    private readonly string _name;
    private string? _occupation;

    public Person(string name, string? occupation)
    {
        _name = name;
        _occupation = occupation;
    }
}

Это особенно полезно при тесной работе в команде. Коллега, создавая объект, сразу из конструктора поймёт поведение класса. Также мы можем более точно определять контракт интерфейса.

public interface IPerson
{
    string Name { get; }
    string? Occupation { get; }
}

Реализуя данный интерфейс, получим такой класс

public class Person : IPerson
{
    public string Name { get; }
    
    public string? Occupation { get; private set; }

    public Person(string name, string? occupation)
    {
        Name = name;
        Occupation = occupation;
    }
}

В ходе разработки кода использующий этот класс IDE будет всячески указывать на места, которые могут нарушать заданную логику. Приведу пример работы с этим классом.

public class People
{
    private readonly Dictionary<string, IPerson> _persons;

    public People(Dictionary<string, IPerson> persons)
    {
        _persons = persons;
    }

    public string GetOccupationByName(string name)
    {
        if (_persons.TryGetValue(name, out var person))
        {
            return person.Occupation;
        }

        return null;
    }
}

Тут мы получим сразу два предупреждения. Мы утверждаем, что метод GetOccupationByName() возвращает string, без возможного null. Но при этом возвращаем null в конце, а так же возвращаем person.Occupation, где уже Occupation может быть null. Задаваемые же нами правила заставляют нас писать код более корректно. Либо указать, что GetOccupationByName() возвращает string?, либо, к примеру, ввести метод TryGetOccupationByName.

public bool TryGetOccupationByName(
    string name,
    [MaybeNullWhen(false)] out string occupation)
{
    if (_persons.TryGetValue(name, out var person))
    {
        occupation = person.Occupation;
        return occupation is not null;
    }

    occupation = null;
    return false;
}

Думаю, вы обратили внимание на атрибут MaybeNullWhen(bool). Интуитивно понятно, что он позволяет указывать для occupation null, при результате false.

Как включить Null reference type в проекте Unity

Конечно, мы всегда можем управлять доступностью Nullable reference type в конкретном месте через директивы #nullable enable, disable или restore. Но как включить эту опцию для всего проекта Unity по умолчанию? 

На данный момент нет возможности это сделать напрямую через настройки в Assembly Definition в самом Unity или через настройки проекта в IDE.

Чтобы включить Nullable reference types для всего проекта Unity расположите файл Directory.Build.props в корневой папке. Содержимое должно быть таким.

<Project>
    <PropertyGroup>
        <Nullable>enable</Nullable>
	</PropertyGroup>
</Project>

Для регулирования отдельных сборок разместите файл csc.rsp с текстом ‘-nullable:enable’ рядом с файлом сборки.

Если вы используете Visual Studio, не должно возникнуть никаких проблем. Для Rider от JetBrains проверьте ваши настройки MSBuild. Откройте настройки File -> Settings. Найдите там раздел “Build, Execution, Deployment” -> “Toolset and Build”, пункт “MSBuild version”. Версия MSBuild должна быть достаточно свежая. У меня с 17.0 все работает.

Сериализуемые поля в MonoBehaviour и ScriptableObject

Для MonoBehaviour и ScriptableObject есть возможность указываться значения некоторых полей в редакторе через инспектор. Получается, что инициализация полей через конструктор не производится. А значит будут предупреждения.

Надеюсь, эту проблему поправят в будущем. А сейчас есть два возможных решения этой проблемы. Отключать данный функционал для области объявления этих полей.

public class Card : MonoBehaviour
{
#nullable disable
   [SerializeField] private string _description;
   [SerializeField] private Sprite _icon;
#nullable restore
}

При это для указаных полей предупреждения перестают работать. К примеру следующий код у анализатора уже не будет вызывать никаких вопросов.

private void Awake()
{
   _icon = null;
}

Поэтому советую применять второй вариант: назначать всем полям значение null!.

public class Card : MonoBehaviour
{
    [SerializeField] private string _description = null!;
    [SerializeField] private Sprite _icon = null!;

    private void Awake()
    {
        _icon = null;
    }
}

Здесь в методе Awake() мы уже получим предупреждение.

Стоит коротко упомянуть, из-за того, что для MonoBehaviour нельзя указывать конструкторы, в некоторых случаях в их роли выступаю обычные методы. Тут мы столкнемся с теми же самыми проблемами. Способы их решение тут точно такие же.

public class Cube : MonoBehaviour
{
   private ICollidingService _collidingService = null!;
  
   public void Initialize(ICollidingService collidingService)
   {
       _collidingService = collidingService;
   }
}

Отсутствие поддержки в библиотеке Unity

На мой взгляд, пока это самая большая проблема, которая может отпугнуть разработчика Unity от использования Nullable reference types. К примеру.

public class Card : MonoBehaviour
{
    [SerializeField] private Card _parent = null!;
    
    private void Awake()
    {
        _parent = transform.parent.GetComponent<Card>();
    }
}

Очевидно, что тут мы должны получить предупреждение, т.к. GetComponent<T> может возвращать null, т.е. T?, но это, к сожалению, пока никак не отображено в библиотеке Unity. Так же печалит факт отсутствия хоть каких либо анонсов исправления этой ситуации.

Заключение

Несмотря на перечисленные проблемы в Unity, я всё же считаю, что стоит начать присматриваться к этому новому функционалу. Постепенно внедрять в свои проекты шаг за шагом. Или пока ограничиваться локальным применением в новых фичах. 

Благодаря Nullable reference types код становится более последовательным и помогает избегать некоторых будущих багов. Эффект особенно заметен, если разработка сильно пересекается между программистами. К примеру, один специалист все еще пишет реализацию интерфейса, где ещё полным полно заглушек, а другой — уже использует этот класс в другом месте. При этом всё ещё не может посмотреть его конечную реализацию.

И конечно же мы ждем от Unity, Rider и Visual Studio каких-то готовых решений упомянутых проблем.