Forma óptima de usar operadores condicionales nulos en expresiones booleanas

Está escribiendo una expresión booleana que podría verse así:

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; }
}

... y obtienes un error:

El operador '&&' no se puede aplicar a operandos de tipo 'bool' y 'bool?'

¿Cuál es la forma óptima / más limpia de manejarlo?

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

   ¿Es eso realmente legible?

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

   Es posible que no funcione en LINQ-to-Entities ...

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

   ¿Realmente escribirías if (condition == true)sin dudarlo?

¿Hay más opciones? ¿Es finalmente mejor escribir:

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

En este caso particular, podría ser prudente seguir la Ley de Deméter, es decir

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

En términos más generales, si una expresión booleana es compleja o fea, entonces no hay nada que decir que no podría dividirla (o parte de ella) en una declaración separada:

bool isVietnamVet = Manager?.IsVietnamVet ?? false;

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

Al recorrer el código en el depurador, a menudo es mejor tener condiciones elaboradas agrupadas en una sola boolpara ahorrar un poco de desplazamiento del mouse; de hecho, podría ser mejor poner todo en una boolvariable.

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;

Creo que la opción 3 (es decir == true) es la forma más limpia de probar que bool?es true, porque es muy claro acerca de lo que hace.

En la mayoría de los códigos x == trueno tiene sentido, porque es lo mismo x, pero eso no se aplica aquí, así que creo == trueque no sería muy confuso.

Ampliando la respuesta de Ben Cottrell, el patrón "Objeto nulo" puede ayudarlo aún más.

En lugar de devolver un nullequipo / gerente, extraiga ITeame IManagerinteractúe y devuelva implementaciones alternativas significativas:

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

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

    public IManager Manager => new NoManager();
}

Entonces, de repente, puedes hacerlo con team.ManagedByVietnamVetseguridad.

Por supuesto, esto depende de que el proveedor ascendente teamsea ​​nulo-seguro, pero eso se puede garantizar con las pruebas adecuadas.

Escribí una clase simple que podrías 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();
        }
    }

Si es confiable usar un tipo personalizado, por supuesto. Puedes comparar MyBoolcon ambos booly Nullable<bool>.