Cuál es preferido: Nullable <>. HasValue o Nullable <>! = Null?

Question

Siempre utilicé (a) Nullable<>.HasValue porque me gustaba la semántica. Sin embargo, recientemente estaba trabajando en la base de códigos existente de otra persona, donde utilizaron (b) Nullable<> != null exclusivamente en su lugar. ¿Hay alguna razón para usar una sobre la otra, o es puramente preferencia?

(a)

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

(b)

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

Answer 1

El compilador reemplaza comparaciones nulos con una llamada a HasValue, por lo que no hay ninguna diferencia real. Simplemente haz lo que sea más legible/tenga más sentido para ti y tus colegas.

Answer 2

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

Answer 3

En VB.Net. NO use "IsNot Nothing" cuando puede usar ".HasValue". Acabo de resolver una "Operación podría desestabilizar el tiempo de ejecución" Error de confianza medio al reemplazar "No es nada" con ".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.

Answer 4

Hice algunas investigaciones sobre esto mediante el uso de diferentes métodos para asignar valores a una int nullable. Esto es lo que sucedió cuando hice varias cosas. Debería aclarar qué está pasando. Tenga en cuenta: Nullable<something> o la abreviatura something? es una estructura para la cual el compilador parece estar haciendo un montón de trabajo para permitirnos usar con nulo como si fuera una clase.
Como verá a continuación, SomeNullable == null y SomeNullable.HasValue siempre devolverán un verdadero o falso esperado. Aunque no se muestra a continuación, SomeNullable == 3 también es válido (suponiendo que SomeNullable es un int?).
Mientras SomeNullable.Value nos muestra un error de tiempo de ejecución si asignamos null a SomeNullable. Este es, de hecho, el único caso en el que los nulables podrían causarnos un problema, gracias a una combinación de operadores sobrecargados, el método object.Equals(obj) sobrecargado y la optimización del compilador y el negocio de los monos.

Aquí es una descripción de un código corría, y lo que la producción se produce 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, vamos a tratar 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 COMPIL, ya que el VALOR del objeto que admite nulos no puede contener nulos. Solo el objeto contenedor puede ser nulo.

Del mismo modo, nos encontraremos con un error de tiempo de compilación de:

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

no

mencionar que val.Value es una propiedad de sólo 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ícitas sobrecargados polimorfas nos permiten hacerlo:

val = 3; 

No hay necesidad de preocuparse por polisomthing whatchamacallits sin embargo, siempre y cuando funcione ¿verdad? :)

Answer 5

Respuesta general y norma general: si tiene una opción (por ejemplo, escribir serializadores personalizados) para procesar Nullable en una canalización distinta de object y usar sus propiedades específicas, hágalo y utilice propiedades específicas anulables. Por lo tanto, desde el punto de vista del pensamiento consistente HasValue debe ser preferido. El pensamiento constante puede ayudarte a escribir un mejor código, no pases demasiado tiempo en los detalles. P. ej. hay segundo método será muchas veces más eficaz (sobre todo debido a los compiladores de procesos en línea y el boxeo, pero todavía 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 se usó

PS La gente dice que esto no está relacionado y es inútil. Se puede predecir el rendimiento de esto:

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

Answer 6

Si utiliza LINQ y desea mantener su código corto, yo recomiendo usar siempre !=null

y es por esto:

Vamos imaginemos que tenemos alguna clase Foo con un anulable doble variables SomeDouble

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 no nulos de SomeDouble de una colección de Foo (asumiendo que algunos foos de la colección también pueden ser nulos), terminamos con al menos tres formas de escribir nuestra función (si usamos C# 6):

public IEnumerable<Foo> GetNonNullFoosWithSomeDoubleValues(IEnumerable<Foo> foos) 
{ 
    return foos.Where(foo => foo?.SomeDouble != null); 
    return foos.Where(foo=>foo?.SomeDouble.HasValue); // will throw an 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 para el más corto