Що краще: Nullable <T> .HasValue або Nullable <T>! = Null?

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

Чи є причина використовувати одне над іншим чи це суто перевагу?

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

vs.

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

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

Я вважаю за краще, (a != null)щоб синтаксис відповідав референтним типам.

Я провів деякі дослідження з цього приводу різних методів, щоб присвоїти значення нульовому int. Ось що сталося, коли я робив різні речі. Слід уточнити, що відбувається. Майте на увазі: Nullable<something>або скорочення something?- це структура, над якою компілятор, здається, робить багато роботи, щоб ми могли використовувати з null так, як якщо б це був клас.
Як ви побачите нижче, 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);нулем, переданим конструктору, спричинила б помилку в часі КОМПЛІЄТНО, оскільки ЗНАЧЕННЯ ЗНАЧЕННЯ об'єкта НЕ зводиться до нуля. Тільки сам об’єкт обгортки може дорівнювати нулю.

Так само ми отримаємо помилку часу компіляції з:

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

не кажучи вже про те, що val.Valueце властивість лише для читання, тобто ми навіть не можемо використовувати щось на зразок:

val.Value = 3;

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

val = 3;

Не потрібно турбуватися про те, що багато чого може бути, але поки це працює правильно? :)

У VB.Net. НЕ використовуйте "IsNot Nothing", коли ви можете використовувати ".HasValue". Я щойно вирішив, що "Операція може дестабілізувати середню помилку виконання", замінивши "IsNot Nothing" на ".HasValue" в одному місці. Я не дуже розумію, чому, але в компіляторі щось відбувається інакше. Я б припустив, що "! = Null" у 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слід використовувати безпосередньо, якщо ви зацікавлені у виконанні.