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

Question

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

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

Sugiere:

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

Esto me parece, una buena práctica tan lógico, y muy auto-documentado. Sin embargo, dudo en comenzar a utilizar esta técnica con regularidad ya que casi nunca me he encontrado con ella; y tal vez sería confuso solo en virtud de ser raro. Sin embargo, mi experiencia no es muy amplia todavía, por lo que me interesa 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 si la ha visto a menudo al leer el código. ¿Es esta una convención/estilo/técnica que vale la pena adoptar? ¿Los otros programadores lo entenderán y lo apreciarán, o lo considerarán extraño?

Answer 1

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

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

Answer 2

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

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

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

bool deleteOnCompletion = true; 

DoSomeMethod(deleteOnCompletion); 

Answer 3

lo he utilizado, aunque normalmente envolver 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 solo lugar.

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

Answer 4

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

Y no estoy de acuerdo con Kevin en su publicación anterior. Su ejemplo, supongo, utilizable en el caso, cuando se puede 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); 

Answer 5

La única manera de que pudiera ver esto va mal es si el fragmento booleano no tiene un nombre que tenga sentido y un nombre se tomó 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 un lugar común para hacer reglas como "comentar todo el código", "uso booleanos nombrados por todas si-criterios con más de 3 partes" sólo para obtener comentarios que son semánticamente vacío de el siguiente tipo

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

Answer 6

al hacer esto

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

se quita el lógica de su cerebro y lo puso en el código. Ahora el programa sabe lo que usted quiso decir.
Cuando nombre algo le da representación física. Existe.
Puede manipularlo y reutilizarlo.

Incluso se puede definir todo el bloque como un predicado:

bool ElementBlahBlah? (elementIndex, lastElementIndex); 

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

Answer 7

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

Answer 8

Recuerde que de esta forma puede calcular más de lo necesario. Debido a las condiciones de salida del código, siempre se calculan ambos (sin cortocircuito).

Así que:

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 todavía en algunos puede significar un peor rendimiento u otros problemas, por ejemplo, cuando en la segunda expresión asumes que el 1er ha fallado.

Answer 9

la muestra proporcionada:

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

Puede también ser reescrito para utilizar métodos, que mejoran la legibilidad y preservar la lógica booleana (como Konrad señaló):

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

Viene a un precio , por supuesto, que son dos métodos adicionales. Si haces esto mucho, puede hacer que tu código sea más legible, pero tus clases menos transparentes. Pero, de nuevo, también puedes mover los métodos extra a clases auxiliares.

Answer 10

Creo que es mejor crear funciones/métodos en lugar de variables temporales. De esta forma, 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".

Answer 11

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 tarde.

Answer 12

En mi experiencia, a menudo volví a algunos guiones antiguos y me preguntaba '¿en qué demonios estaba pensando 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; 
}; 

Answer 13

rara vez crear variables independientes. Lo que hago cuando las pruebas se complican es anidar las IF y agregar comentarios. Al igual que

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 en esta técnica es que el próximo programador que viene puede cambiar la lógica, pero no se molestan en actualizar los comentarios. Supongo que es un problema general, pero he tenido muchas veces que he visto un comentario que dice "validar la identificación del cliente" y la siguiente línea está examinando el número de parte o algo así y me pregunto dónde está el cliente. Identificación viene en

Answer 14

si el método requiere una notificación de éxito:. (ejemplos en C#) me gusta usar la

bool success = false; 

para empezar. el código es un falure hasta que cambie a:

success = true; 

luego, al final:

return success;