Maneira ideal de usar operadores condicionais nulos em expressões booleanas

Você está escrevendo uma expressão booleana que pode ser assim:

team.Category == "A Team" && team?.Manager?.IsVietnamVet

public class Manager
{
    public bool IsVietnamVet { get; set; }
}

public class Team
{
    public string Category { get; set; }

    public Manager Manager { get; set; }
}

... e você recebe um erro:

O operador '&&' não pode ser aplicado a operandos do tipo 'bool' e 'bool?'

Qual é a maneira ideal / mais limpa de lidar com isso?

1. team.Category == "A Team" && (team?.Manager?.IsVietnamVet ?? false)

   Isso é realmente legível?

2. team.Category == "A Team" && (team?.Manager?.IsVietnamVet).GetValueOrDefault()

   Pode não funcionar no LINQ-to-Entities ...

3. team.Category == "A Team" && team?.Manager?.IsVietnamVet == true

   Você realmente escreveria if (condition == true)sem hesitar?

Existem outras opções? Em última análise, é melhor escrever:

4. team.Category == "A Team" && team.Manager != null && team.Manager.IsVietnamVet

Nesse caso em particular, pode ser prudente seguir a Lei de Deméter, ou seja,

public class Team
{
    public bool IsManagerVietnamVet => Manager?.IsVietnamVet ?? false;
}    

De maneira mais geral, se uma expressão booleana é complexa ou feia, não há nada a dizer que você não possa dividi-la (ou parte dela) em uma declaração separada:

bool isVietnamVet = Manager?.IsVietnamVet ?? false;

if (team.Category == "A Team" && isVietnamVet)

Ao percorrer o código no depurador, geralmente é melhor ter condições elaboradas agrupadas em um único boolapenas para economizar um pouco de pairar o mouse; de fato, pode ser melhor colocar a coisa toda em uma boolvariável.

bool isVietnamVetAndCategoryA = (team.Category == "A Team"
    && Manager?.IsVietnamVet ?? false);

if (isVietnamVetAndCategoryA)

ou com LINQ:

var wibble = from flight in airport
             from passenger in flight.manifest
             let isOnPlane = 
                 (flight.FinishedBoarding && passenger.Flight == flight.FlightNumber)
             where !isOnPlane
             select passenger;

Eu acho que a opção 3 (ie == true) é a maneira mais limpa de teste que um bool?é true, porque é muito claro sobre o que ele faz.

Na maioria dos códigos x == true, não faz sentido, porque é o mesmo que x, mas isso não se aplica aqui, então acho == trueque não seria muito confuso.

Expandindo a resposta de Ben Cottrell, o padrão "Objeto nulo" pode ajudá-lo ainda mais.

Em vez de retornar uma nullequipe / gerente, extraia ITeame faça IManagerinterfaces e retorne implementações alternativas significativas:

public class NoManager : IManager
{
    public bool IsVietnamVet => false;
}

public class NoTeam : ITeam
{
    public bool ManagedByVietnamVet => false;

    public IManager Manager => new NoManager();
}

De repente, você pode fazer team.ManagedByVietnamVetcom segurança.

Obviamente, isso depende do provedor upstream teamcomo sendo seguro para nulos - mas isso pode ser garantido com testes apropriados.

Eu escrevi uma classe simples que você poderia usar:

 public class MyBool 
    {
        public bool? Value { get; set; }

        public MyBool(bool b)
        {
            Value = b;
        }

        public MyBool(bool? b)
        {
            Value = b;
        }

        public static implicit operator bool(MyBool m)
        {
            return m?.Value ?? false;
        }

        public static implicit operator bool?(MyBool m)
        {
            return m?.Value;
        }

        public static implicit operator MyBool(bool m)
        {
            return new MyBool(m);
        }

        public static implicit operator MyBool(bool? m)
        {
            return new MyBool(m);
        }

        public override string ToString()
        {
            return Value.ToString();
        }
    }

Se for confiável usar um tipo personalizado, é claro. Você pode comparar MyBoolcom ambos boole Nullable<bool>.