Modo ottimale per utilizzare operatori condizionali nulli nelle espressioni booleane

Stai scrivendo un'espressione booleana che potrebbe apparire così:

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 ricevi un errore:

L'operatore "&&" non può essere applicato agli operandi di tipo "bool" e "bool?"

Qual è il modo ottimale / più pulito per gestirlo?

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

   È davvero leggibile?

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

   Potrebbe non funzionare in LINQ-to-Entities ...

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

   Scriveresti davvero if (condition == true)senza alcuna esitazione?

Ci sono altre opzioni? Alla fine è meglio scrivere:

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

In questo caso particolare, potrebbe essere saggio seguire la Legge di Demetra, cioè

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

Più in generale, se un'espressione booleana è complessa o brutta, non c'è nulla da dire che non puoi dividerla (o parte di essa) in un'istruzione separata:

bool isVietnamVet = Manager?.IsVietnamVet ?? false;

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

Quando si passa attraverso il codice nel debugger, è spesso più bello avere condizioni elaborate raggruppate in un singolo boolsolo per risparmiare un po 'di passaggio del mouse; in effetti, potrebbe essere più bello mettere il tutto in una boolvariabile.

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

if (isVietnamVetAndCategoryA)

o con LINQ:

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

Credo che l'opzione 3 (cioè == true) è il modo più pulito per un test che bool?è true, perché è molto chiaro su quello che fa.

Nella maggior parte del codice x == truenon ha senso, perché è lo stesso di x, ma non si applica qui, quindi penso == trueche non sarebbe molto confuso.

Espandendo la risposta di Ben Cottrell, il modello "Null Object" può aiutarti ulteriormente.

Invece di restituire un nullteam / manager, estrai ITeame IManagerinterfacce e restituisci implementazioni alternative significative:

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

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

    public IManager Manager => new NoManager();
}

Quindi all'improvviso puoi fare in team.ManagedByVietnamVetsicurezza.

Questo ovviamente si basa sul fatto che il fornitore a monte teamsia sicuro per nulla, ma ciò può essere garantito con test adeguati.

Ho scritto una classe semplice che potresti usare:

 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 affidabile per usare un tipo personalizzato, ovviamente. Puoi confrontare MyBoolcon entrambi boole Nullable<bool>.