Qual é o preferido: Nullable <T> .HasValue ou Nullable <T>! = Null?

Eu sempre usei Nullable<>.HasValueporque gostei da semântica. No entanto, recentemente eu estava trabalhando na base de código existente de outra pessoa, onde ela usava Nullable<> != nullexclusivamente.

Existe uma razão para usar um sobre o outro, ou é pura preferência?

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

vs.

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

O compilador substitui comparações nulas por uma chamada para HasValue, portanto, não há diferença real. Faça o que for mais legível / faça mais sentido para você e seus colegas.

Eu prefiro (a != null)que a sintaxe corresponda aos tipos de referência.

Eu fiz algumas pesquisas sobre isso usando métodos diferentes para atribuir valores a um int nulo. Aqui está o que aconteceu quando eu fiz várias coisas. Deve esclarecer o que está acontecendo. Lembre-se: Nullable<something>ou a abreviação something?é uma estrutura para a qual o compilador parece estar fazendo muito trabalho para nos deixar usar com nulo como se fosse uma classe.
Como você verá abaixo, SomeNullable == nulle SomeNullable.HasValuesempre retornará um esperado verdadeiro ou falso. Embora não demonstrado abaixo, também SomeNullable == 3é válido (assumindo que SomeNullable é um int?).
Enquanto SomeNullable.Valueisso, obtemos um erro de tempo de execução se atribuímos nullao método, otimização do compilador e negócios de macaco.SomeNullable . Este é, de fato, o único caso em que anuláveis ​​podem nos causar um problema, graças a uma combinação de operadores sobrecarregados, sobrecarregados.object.Equals(obj)

Aqui está uma descrição de algum código que eu executei e qual saída ele produziu nos rótulos:

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 tentar o próximo método de inicialização:

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

Tudo o mesmo de antes. Lembre-se de que a inicialização com int? val = new int?(null);, com nulo passado para o construtor, teria produzido um erro de tempo COMPILE, pois VALUE do objeto anulável NÃO é anulável. É apenas o próprio objeto wrapper que pode ser igual a nulo.

Da mesma forma, receberíamos um erro de tempo de compilação em:

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

para não mencionar que val.Valueé uma propriedade somente leitura de qualquer maneira, o que significa que não podemos nem usar algo como:

val.Value = 3;

mas, novamente, operadores de conversão implícita sobrecarregados polimórficos nos permitem:

val = 3;

Não há necessidade de se preocupar com o que você chama de polissom, desde que funcione corretamente? :)

No VB.Net. NÃO use "IsNot Nothing" quando puder usar ".HasValue". Acabei de solucionar um erro de confiança médio "A operação poderia desestabilizar o tempo de execução", substituindo "IsNot Nothing" por ".HasValue" em um único local. Eu realmente não entendo o porquê, mas algo está acontecendo de maneira diferente no compilador. Eu diria que "! = Null" em C # pode ter o mesmo problema.

Se você usa linq e deseja manter seu código curto, recomendo sempre usar !=null

E é por isso que:

Vamos imaginar que temos alguma classe Foocom uma variável dupla anulávelSomeDouble

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

Se em algum lugar do código queremos obter todos os Foo com valores SomeDouble não nulos de uma coleção de Foo (supondo que alguns foos na coleção também possam ser nulos), terminamos com pelo menos três maneiras de escrever nossa função (se 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
}

E nesse tipo de situação eu recomendo sempre ir para a mais curta

Resposta geral e regra geral: se você tiver uma opção (por exemplo, escrever serializadores personalizados) para processar Nullable em pipeline diferente de object- e usar suas propriedades específicas - faça-o e use propriedades específicas Nullable. Portanto, do ponto de vista do pensamento consistente, HasValuedeve ser preferido. O pensamento consistente pode ajudá-lo a escrever um código melhor, sem gastar muito tempo em detalhes. Por exemplo, o segundo método será muitas vezes mais eficaz (principalmente por causa dos compiladores embutidos e do boxe, mas os números ainda são muito expressivos):

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

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

Teste de benchmark:

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 referência:

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 foi usado

PS . As pessoas dizem que o conselho "prefere o HasValue por causa de um pensamento consistente" não é relacionado e inútil. Você pode prever o desempenho disso?

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

PPS As pessoas continuam menos, mas ninguém tenta prever o desempenho de CheckNullableGenericImpl. E há compilador não irá ajudá-lo a substituir !=nullcom HasValue. HasValuedeve ser usado diretamente se você estiver interessado em desempenho.