Что предпочтительнее: Nullable <T> .HasValue или Nullable <T>! = Null?

Я всегда использовал, Nullable<>.HasValueпотому что мне понравилась семантика. Тем не менее, недавно я работал над чьей-либо существующей кодовой базой, где они использовали Nullable<> != nullисключительно вместо этого.

Есть ли причина использовать один над другим или это просто предпочтение?

1. int? a;
   if (a.HasValue)
       // ...
   

против

2. int? b;
   if (b != null)
       // ...
   

Компилятор заменяет пустые сравнения на вызовы HasValue, поэтому разницы нет. Просто делайте то, что лучше для чтения / имеет больше смысла для вас и ваших коллег.

Я предпочитаю, (a != null)чтобы синтаксис соответствовал ссылочным типам.

Я провел некоторое исследование по этому вопросу, используя различные методы для присвоения значений обнуляемому int. Вот что случилось, когда я делал разные вещи. Следует уточнить, что происходит. Имейте в виду: Nullable<something>или сокращение something?- это структура, для которой компилятор, кажется, проделывает большую работу, чтобы позволить нам использовать с нулем, как если бы это был класс.
Как вы увидите ниже, SomeNullable == nullи SomeNullable.HasValueвсегда будет возвращать ожидаемый истинным или ложным. Хотя это и не показано ниже, SomeNullable == 3это также верно (если предположить, что SomeNullable является int?).
В то время как SomeNullable.Valueполучает нам сообщение об ошибке выполнения , если мы назначили nullна SomeNullable. Фактически это единственный случай, когда обнуляемые значения могут вызвать у нас проблему, благодаря комбинации перегруженных операторов, перегруженныхobject.Equals(obj) метод и оптимизация компилятора и бизнес обезьян.

Вот описание некоторого кода, который я запустил, и какой вывод он произвел в метках:

int? val = null;
lbl_Val.Text = val.ToString(); //Produced an empty string.
lbl_ValVal.Text = val.Value.ToString(); //Produced a runtime error. ("Nullable object must have a value.")
lbl_ValEqNull.Text = (val == null).ToString(); //Produced "True" (without the quotes)
lbl_ValNEqNull.Text = (val != null).ToString(); //Produced "False"
lbl_ValHasVal.Text = val.HasValue.ToString(); //Produced "False"
lbl_NValHasVal.Text = (!(val.HasValue)).ToString(); //Produced "True"
lbl_ValValEqNull.Text = (val.Value == null).ToString(); //Produced a runtime error. ("Nullable object must have a value.")
lbl_ValValNEqNull.Text = (val.Value != null).ToString(); //Produced a runtime error. ("Nullable object must have a value.")

Хорошо, давайте попробуем следующий метод инициализации:

int? val = new int?();
lbl_Val.Text = val.ToString(); //Produced an empty string.
lbl_ValVal.Text = val.Value.ToString(); //Produced a runtime error. ("Nullable object must have a value.")
lbl_ValEqNull.Text = (val == null).ToString(); //Produced "True" (without the quotes)
lbl_ValNEqNull.Text = (val != null).ToString(); //Produced "False"
lbl_ValHasVal.Text = val.HasValue.ToString(); //Produced "False"
lbl_NValHasVal.Text = (!(val.HasValue)).ToString(); //Produced "True"
lbl_ValValEqNull.Text = (val.Value == null).ToString(); //Produced a runtime error. ("Nullable object must have a value.")
lbl_ValValNEqNull.Text = (val.Value != null).ToString(); //Produced a runtime error. ("Nullable object must have a value.")

Все так же, как и раньше. Имейте в виду, что инициализация с int? val = new int?(null);нулем, переданным в конструктор, привела бы к ошибке времени COMPILE, так как значение VALUE объекта, допускающего значение NULL, НЕ может иметь значение NULL. Только сам объект-оболочка может равняться нулю.

Аналогично, мы получили бы ошибку времени компиляции из:

int? val = new int?();
val.Value = null;

не говоря уже о том, что val.Valueэто свойство только для чтения, то есть мы не можем даже использовать что-то вроде:

val.Value = 3;

но опять же, полиморфные перегруженные операторы неявного преобразования позволят нам сделать:

val = 3;

Не нужно беспокоиться о том, что может случиться, если это работает правильно? :)

В VB.Net. НЕ используйте «IsNot Nothing», когда вы можете использовать «.HasValue». Я только что решил «Операция могла дестабилизировать среду выполнения» Ошибка среднего доверия, заменив «IsNot Nothing» на «.HasValue» в одном месте. Я не очень понимаю, почему, но что-то происходит по-другому в компиляторе. Я хотел бы предположить, что "! = Нуль" в C # может иметь ту же проблему.

Если вы используете linq и хотите, чтобы ваш код был коротким, я рекомендую всегда использовать !=null

И вот почему:

Давайте представим, что у нас есть некоторый класс Fooс двойной переменнойSomeDouble

public class Foo
{
    public double? SomeDouble;
    //some other properties
}   

Если где-то в нашем коде мы хотим получить все значения Foo с ненулевыми значениями SomeDouble из коллекции Foo (при условии, что некоторые значения foos в коллекции тоже могут быть нулевыми), мы получим как минимум три способа написания нашей функции (если мы используйте C # 6):

public IEnumerable<Foo> GetNonNullFoosWithSomeDoubleValues(IEnumerable<Foo> foos)
{
     return foos.Where(foo => foo?.SomeDouble != null);
     return foos.Where(foo=>foo?.SomeDouble.HasValue); // compile time error
     return foos.Where(foo=>foo?.SomeDouble.HasValue == true); 
     return foos.Where(foo=>foo != null && foo.SomeDouble.HasValue); //if we don't use C#6
}

И в такой ситуации я рекомендую всегда идти на более короткий

Общий ответ и практическое правило: если у вас есть возможность (например, написание пользовательских сериализаторов) обрабатывать Nullable в другом конвейере, чем object- и использовать их специфические свойства - делайте это и используйте специфические свойства Nullable. Так что с точки зрения последовательного мышления HasValueследует отдавать предпочтение. Последовательное мышление может помочь вам написать лучший код, не тратя слишком много времени на детали. Например, второй метод будет во много раз эффективнее (в основном из-за встраивания компиляторов и бокса, но все же числа очень выразительны):

public static bool CheckObjectImpl(object o)
{
    return o != null;
}

public static bool CheckNullableImpl<T>(T? o) where T: struct
{
    return o.HasValue;
}

Контрольный тест:

BenchmarkDotNet=v0.10.5, OS=Windows 10.0.14393
Processor=Intel Core i5-2500K CPU 3.30GHz (Sandy Bridge), ProcessorCount=4
Frequency=3233539 Hz, Resolution=309.2587 ns, Timer=TSC
  [Host] : Clr 4.0.30319.42000, 64bit RyuJIT-v4.6.1648.0
  Clr    : Clr 4.0.30319.42000, 64bit RyuJIT-v4.6.1648.0
  Core   : .NET Core 4.6.25009.03, 64bit RyuJIT


        Method |  Job | Runtime |       Mean |     Error |    StdDev |        Min |        Max |     Median | Rank |  Gen 0 | Allocated |
-------------- |----- |-------- |-----------:|----------:|----------:|-----------:|-----------:|-----------:|-----:|-------:|----------:|
   CheckObject |  Clr |     Clr | 80.6416 ns | 1.1983 ns | 1.0622 ns | 79.5528 ns | 83.0417 ns | 80.1797 ns |    3 | 0.0060 |      24 B |
 CheckNullable |  Clr |     Clr |  0.0029 ns | 0.0088 ns | 0.0082 ns |  0.0000 ns |  0.0315 ns |  0.0000 ns |    1 |      - |       0 B |
   CheckObject | Core |    Core | 77.2614 ns | 0.5703 ns | 0.4763 ns | 76.4205 ns | 77.9400 ns | 77.3586 ns |    2 | 0.0060 |      24 B |
 CheckNullable | Core |    Core |  0.0007 ns | 0.0021 ns | 0.0016 ns |  0.0000 ns |  0.0054 ns |  0.0000 ns |    1 |      - |       0 B |

Код теста:

public class BenchmarkNullableCheck
{
    static int? x = (new Random()).Next();

    public static bool CheckObjectImpl(object o)
    {
        return o != null;
    }

    public static bool CheckNullableImpl<T>(T? o) where T: struct
    {
        return o.HasValue;
    }

    [Benchmark]
    public bool CheckObject()
    {
        return CheckObjectImpl(x);
    }

    [Benchmark]
    public bool CheckNullable()
    {
        return CheckNullableImpl(x);
    }
}

https://github.com/dotnet/BenchmarkDotNet был использован

PS . Люди говорят, что совет «предпочитаю HasValue из-за последовательного мышления» не связан и бесполезен. Можете ли вы предсказать производительность этого?

public static bool CheckNullableGenericImpl<T>(T? t) where T: struct
{
    return t != null; // or t.HasValue?
}

Люди PPS продолжают минус, но никто не пытается предсказать производительность CheckNullableGenericImpl. И там компилятор не поможет вам заменить !=nullна HasValue. HasValueследует использовать напрямую, если вы заинтересованы в производительности.