¿Qué se prefiere: Nullable <T> .HasValue o Nullable <T>! = Null?

Siempre solía Nullable<>.HasValueporque me gustaba la semántica. Sin embargo, recientemente estaba trabajando en la base de código existente de otra persona donde la usaban Nullable<> != nullexclusivamente.

¿Hay alguna razón para usar uno sobre el otro, o es puramente preferencial?

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

vs.

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

El compilador reemplaza las comparaciones nulas con una llamada a HasValue, por lo que no hay una diferencia real. Simplemente haga lo que sea más legible / tenga más sentido para usted y sus colegas.

Prefiero (a != null)que la sintaxis coincida con los tipos de referencia.

Investigué un poco sobre esto mediante el uso de diferentes métodos para asignar valores a un int anulable. Esto es lo que sucedió cuando hice varias cosas. Debería aclarar lo que está pasando. Tenga en cuenta: Nullable<something>o la taquigrafía something?es una estructura para la cual el compilador parece estar haciendo mucho trabajo para permitirnos usar con nulo como si fuera una clase.
Como verá a continuación, SomeNullable == nully SomeNullable.HasValuesiempre devolverá un verdadero o falso esperado. Aunque no se muestra a continuación, también SomeNullable == 3es válido (suponiendo que SomeNullable es un int?).
Aunque SomeNullable.Valueno nos lleva a un error de ejecución, si asignamos nulla SomeNullable. De hecho, este es el único caso en el que los valores nulables pueden causarnos un problema, gracias a una combinación de operadores sobrecargados, sobrecargadosobject.Equals(obj) método y optimización del compilador y negocios de monos.

Aquí hay una descripción de algún código que ejecuté y qué salida produjo en las etiquetas:

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.")

Ok, intentemos el siguiente método de inicialización:

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.")

Todo lo mismo que antes. Tenga en cuenta que la inicialización con int? val = new int?(null);, con nulo pasado al constructor, habría producido un error de tiempo de COMPILACIÓN, ya que el VALOR del objeto anulable NO es anulable. Es solo el objeto contenedor lo que puede ser igual a nulo.

Del mismo modo, obtendríamos un error de tiempo de compilación de:

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

sin mencionar que val.Valuees una propiedad de solo lectura de todos modos, lo que significa que ni siquiera podemos usar algo como:

val.Value = 3;

pero de nuevo, los operadores de conversión implícita sobrecargados polimorfos nos permiten hacer:

val = 3;

Sin embargo, no es necesario preocuparse por lo polis que puede hacer, siempre y cuando funcione correctamente. :)

En VB.Net. NO use "IsNot Nothing" cuando pueda usar ".HasValue". Acabo de resolver un error de confianza medio "Operación podría desestabilizar el tiempo de ejecución" reemplazando "IsNot Nothing" por ".HasValue" en un solo lugar. Realmente no entiendo por qué, pero algo está sucediendo de manera diferente en el compilador. Supongo que "! = Null" en C # puede tener el mismo problema.

Si usa linq y quiere mantener su código corto, recomiendo usar siempre !=null

Y esta es la razón:

Imaginemos que tenemos alguna clase Foocon una variable doble anulableSomeDouble

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

Si en algún lugar de nuestro código queremos obtener todos los Foo con valores SomeDouble no nulos de una colección de Foo (suponiendo que algunos foos en la colección también puedan ser nulos), terminamos con al menos tres formas de escribir nuestra función (si use 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
}

Y en este tipo de situación recomiendo ir siempre por la más corta

Respuesta general y regla general: si tiene una opción (por ejemplo, escribir serializadores personalizados) para procesar Nullable en una canalización diferente que object, y usar sus propiedades específicas, hágalo y use propiedades específicas de Nullable. Por lo tanto, desde un punto de vista de pensamiento consistente, HasValuedebería preferirse. El pensamiento consistente puede ayudarlo a escribir un mejor código sin perder demasiado tiempo en detalles. Por ejemplo, el segundo método será muchas veces más efectivo (principalmente debido a los compiladores en línea y boxeo, pero aún así los números son muy expresivos):

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

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

Prueba de referencia:

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 |

Código de referencia:

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 fue utilizado

PS . La gente dice que el consejo "prefiere HasValue debido a un pensamiento constante" no está relacionado e inútil. ¿Puedes predecir el rendimiento de esto?

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

PPS Las personas continúan negativas pero nadie intenta predecir el rendimiento de CheckNullableGenericImpl. Y hay compilador no le ayudará a reemplazar !=nullcon HasValue. HasValuedebe usarse directamente si está interesado en el rendimiento.