¿Existen recomendaciones de guías de estilo o convenciones para formatear lógica booleana compleja?

Question

Trabajé en un proyecto que involucraba lógica booleana compleja. Esta complejidad hizo que el código fuera muy eficiente, pero desafortunadamente difícil de leer.

Así que establecimos la lógica como a continuación, lo que hizo más fácil ver los grupos dentro de las declaraciones compuestas, y también hizo posible agregar comentarios a partes de la lógica.

(Este código no es código real del proyecto, la lógica real era más compleja)

¿Alguna vez ha visto este hecho en otro sitio?

¿Existen convenciones o recomendaciones de guías de estilo sobre cómo diseñar una lógica booleana muy compleja?

Answer 1

Refactorizaría el código para usar métodos externos para facilitar la lectura.

if(ValidAngle(angle, previousAngle) && ValidAngle(pairedAngle, previousPairedAngle)) 

ValidAngle(angle, prevAngle){ 
    return angle.angle < kQuiteLow && (previousAngle.angle > kQuiteHigh || previousAngle.time == kUnknownTime) 
} 

Answer 2

Una sugerencia es romper la lógica en los métodos. También es más fácil transformar tus comentarios en el nombre del método, por lo que no los necesitarás. O, si son demasiado complejos, se incluyen en la documentación del método.

if (anglesAreOk(...)) 
{ 
} 

public bool analyseAngles() { 
    return angleOk(...) && previousAngleOk(...) && pairedAngleOk(...) 
} 

Usted g.t la idea ...

Answer 3

Estoy de acuerdo con samuelcarrijo y Pb, extraer las expresiones complejas en cualquiera de los métodos o variables.

Si no puede extraer un método para una abstracción significativa, puede considerar code fragments or blocks.

Answer 4

Del libro de refactorización de Fowler, estoy de acuerdo con el consejo de que la lógica booleana compleja debe reemplazarse por métodos con nombres significativos, p.

if(x && y || !b) { } 

vs

if(customerIsRepeatCustomerFromIdaho(x,y,b)){ } 

o una variedad de pruebas de unidad con nombres significativos

por ejemplo

[Test] 
public void CustomersFromIdahoGetDiscountsOnAlternatingTuesdays() 
{ 
    isRepeat=true;isFromIdaho=false;isTuesday=true; 
    Assert.AreEqual(Customer.CalclateDiscount(isRepeat,isFromIdaho,isTuesday),.10) 
} 

Answer 5

¿Qué le parece agregar los límites a sus clases?

p. Ej.

if (angle.isQuiteLow() && previousAngle.isQuiteHigh() && previousAngle.isUnknownTime())