¿Deberían los programadores utilizar variables booleanas para "documentar" su código?

Estoy leyendo Code Complete de McConell , y él analiza el uso de variables booleanas para documentar su código. Por ejemplo, en lugar de:

if((elementIndex < 0) || (MAX_ELEMENTS < elementIndex) || 
   (elementIndex == lastElementIndex)){
       ...
}

Él sugiere:

finished = ((elementIndex < 0) || (MAX_ELEMENTS < elementIndex));
repeatedEntry = (elementIndex == lastElementIndex);
if(finished || repeatedEntry){
   ...
}

Esto me parece lógico, una buena práctica y muy autodocumentado. Sin embargo, dudo en empezar a utilizar esta técnica con regularidad, ya que casi nunca me he encontrado con ella; y quizás sería confuso solo por ser raro. Sin embargo, mi experiencia aún no es muy amplia, por lo que estoy interesado en escuchar la opinión de los programadores sobre esta técnica, y me gustaría saber si alguien usa esta técnica con regularidad o la ha visto con frecuencia al leer código. ¿Es esta una convención / estilo / técnica que vale la pena adoptar? ¿Lo entenderán y apreciarán otros programadores, o lo considerarán extraño?

Dividir una expresión que está demasiado anidada y complicada en subexpresiones más simples asignadas a variables locales, y luego juntas de nuevo, es una técnica bastante común y popular, independientemente de si las subexpresiones y / o la expresión general son booleanas o de casi cualquier otro tipo. Con nombres bien elegidos, una descomposición elegante de este tipo puede aumentar la legibilidad, y un buen compilador no debería tener problemas para generar un código equivalente a la complicada expresión original.

Algunos lenguajes que no tienen el concepto de "asignación" per se, como Haskell, incluso introducen construcciones especializadas para permitirle usar la técnica "dar un nombre a una subexpresión" (la wherecláusula en Haskell) - parece indicar algo popularidad de la técnica en cuestión! -)

Lo he usado, aunque normalmente envuelvo la lógica booleana en un método reutilizable (si se llama desde múltiples ubicaciones).

Ayuda a la legibilidad y cuando la lógica cambia, solo necesita cambiarse en un lugar.

Otros lo entenderán y no lo encontrarán extraño (excepto para aquellos que solo escriben funciones de mil líneas, es decir).

Intento hacerlo siempre que sea posible. Seguro, está utilizando una "línea adicional" de código, pero al mismo tiempo, está describiendo por qué está haciendo una comparación de dos valores.

En su ejemplo, miro el código y me pregunto "¿por qué la persona que ve que el valor es menor que 0?" En el segundo me estás diciendo claramente que algunos procesos han finalizado cuando esto ocurre. Sin adivinar en el segundo cuál era tu intención.

El más importante para mí es cuando veo un método como: DoSomeMethod(true); ¿Por qué se establece automáticamente en verdadero? Es mucho más legible como

bool deleteOnCompletion = true;

DoSomeMethod(deleteOnCompletion);

La muestra proporcionada:

finished = ((elementIndex < 0) || (MAX_ELEMENTS < elementIndex));
repeatedEntry = (elementIndex == lastElementIndex);
if(finished || repeatedEntry){
   ...
}

También se puede reescribir para usar métodos, que mejoran la legibilidad y preservan la lógica booleana (como señaló Konrad):

if (IsFinished(elementIndex) || IsRepeatedEntry(elementIndex, lastElementIndex)){
   ...
}

...

private bool IsFinished(int elementIndex) {
    return ((elementIndex < 0) || (MAX_ELEMENTS < elementIndex));
}

private bool IsRepeatedEntry(int elementIndex, int lastElementIndex) {
    return (elementIndex == lastElementIndex);
}

Tiene un precio, por supuesto, que son dos métodos adicionales. Si hace esto mucho, puede hacer que su código sea más legible, pero sus clases menos transparentes. Pero, de nuevo, también puede mover los métodos adicionales a clases auxiliares.

La única forma en que podría ver que esto va mal es si el fragmento booleano no tiene un nombre que tenga sentido y se elige un nombre de todos modos.

//No clue what the parts might mean.
if(price>0 && (customer.IsAlive || IsDay(Thursday)))

=>

first_condition = price>0
second_condition =customer.IsAlive || IsDay(Thursday)

//I'm still not enlightened.
if(first_condition && second_condition)

Señalo esto porque es común hacer reglas como "comentar todo tu código", "usar booleanos con nombre para todos los criterios if con más de 3 partes" solo para obtener comentarios que están semánticamente vacíos del siguiente tipo

i++; //increment i by adding 1 to i's previous value

Al hacer esto

finished = ((elementIndex < 0) || (MAX_ELEMENTS < elementIndex));
repeatedEntry = (elementIndex == lastElementIndex);
if(finished || repeatedEntry){
   ...
}

eliminas la lógica de tu cerebro y la pones en el código. Ahora el programa sabe lo que quiso decir.
Siempre que nombras algo, le das una representación física . Existe.
Puedes manipularlo y reutilizarlo.

Incluso puede definir todo el bloque como un predicado:

bool ElementBlahBlah? (elementIndex, lastElementIndex);

y hacer más cosas (más adelante) en esa función.

Si la expresión es compleja, la muevo a otra función que devuelve un boolejemplo, isAnEveningInThePubAGoodIdea(dayOfWeek, sizeOfWorkLoad, amountOfSpareCash)o reconsidero el código para que no se requiera una expresión tan compleja.

Recuerda que de esta forma calculas más de lo necesario. Debido a que se eliminan las condiciones del código, siempre se calculan ambas (sin cortocircuito).

Así que eso:

if((elementIndex < 0) || (MAX_ELEMENTS < elementIndex) || 
   (elementIndex == lastElementIndex)){
   ...
}

Después de la transformación se convierte en:

if((elementIndex < 0) || (MAX_ELEMENTS < elementIndex) |
   (elementIndex == lastElementIndex)){
   ...
}

No es un problema en la mayoría de los casos, pero aún en algunos puede significar un peor rendimiento u otros problemas, por ejemplo, cuando en la segunda expresión asume que la primera ha fallado.

Creo que es mejor crear funciones / métodos en lugar de variables temporales. De esta manera, la legibilidad aumenta también porque los métodos se acortan. El libro Refactoring de Martin Fowler tiene buenos consejos para mejorar la calidad del código. Las refactorizaciones relacionadas con su ejemplo particular se denominan "Reemplazar temperatura con consulta" y "Método de extracción".

Personalmente, creo que esta es una gran práctica. Su impacto en la ejecución del código es mínimo, pero la claridad que puede proporcionar, si se usa correctamente, es invaluable cuando se trata de mantener el código más adelante.

si el método requiere una notificación de éxito: (ejemplos en c #) Me gusta usar el

bool success = false;

para empezar. el código es falso hasta que lo cambio a:

success = true;

luego al final:

return success;

Creo que depende del estilo que prefiera usted o su equipo. La refactorización "Introducir variable" podría ser útil, pero a veces no :)

Y debería estar en desacuerdo con Kevin en su publicación anterior. Su ejemplo, supongo, utilizable en caso de que se pueda cambiar la variable introducida, pero introducirla solo para un booleano estático es inútil, porque tenemos el nombre del parámetro en una declaración de método, entonces, ¿por qué duplicarlo en el código?

por ejemplo:

void DoSomeMethod(boolean needDelete) { ... }

// useful
boolean deleteOnCompletion = true;
if ( someCondition ) {
    deleteOnCompletion = false;
}
DoSomeMethod(deleteOnCompletion);

// useless
boolean shouldNotDelete = false;
DoSomeMethod(shouldNotDelete);

En mi experiencia, a menudo volví a algunos guiones antiguos y me preguntaba '¿qué diablos estaba pensando en ese entonces?'. Por ejemplo:

Math.p = function Math_p(a) {
    var r = 1, b = [], m = Math;
    a = m.js.copy(arguments);
    while (a.length) {
        b = b.concat(a.shift());
    }
    while (b.length) {
        r *= b.shift();
    }
    return r;
};

que no es tan intuitivo como:

/**
 * An extension to the Math object that accepts Arrays or Numbers
 * as an argument and returns the product of all numbers.
 * @param(Array) a A Number or an Array of numbers.
 * @return(Number) Returns the product of all numbers.
 */
Math.product = function Math_product(a) {
    var product = 1, numbers = [];
    a = argumentsToArray(arguments);
    while (a.length) {
        numbers = numbers.concat(a.shift());
    }
    while (numbers.length) {
        product *= numbers.shift();
    }
    return product;
};

Rara vez creo variables separadas. Lo que hago cuando las pruebas se complican es anidar los IF y agregar comentarios. Me gusta

boolean processElement=false;
if (elementIndex < 0) // Do we have a valid element?
{
  processElement=true;
}
else if (elementIndex==lastElementIndex) // Is it the one we want?
{
  processElement=true;
}
if (processElement)
...

El defecto admitido de esta técnica es que el próximo programador que se presente puede cambiar la lógica pero no se molestará en actualizar los comentarios. Supongo que es un problema general, pero muchas veces he visto un comentario que dice "validar la identificación del cliente" y la siguiente línea es examinar el número de pieza o algo así y me pregunto dónde está el cliente. entra id.