2010-01-25 9 views
5

Ok - Tengo a alguien que trabajo que ha escrito algo como esto¿Cuántas combinaciones en esta declaración Si

if() 
    if() 
     if() 
     if() 
     if() 

No me gusta esto !!

Si hay diez banderas booleanas diferentes, ¿cuántas combinaciones hay?

10 factorial?

que estoy tratando de explicar por qué esto es malo

+0

estoy interesado en cómo refactorizar el código ... –

+0

no veo por qué esto es malo, podría ser la mejor manera de resolver el problema en el que está trabajando – harryovers

+0

Habrá la misma cantidad de banderas y combinaciones, sin importar cómo organices tu 'si's. – Kobi

Respuesta

2

dos estados por bandera y 10 banderas significa que 2^10 = 1024

3

2 en el 10 ° grado = 1024

que estoy tratando de explicar por qué esto es malo

Esto no necesariamente puede ser mala . Cada condición corta la mitad de los casos. Si sabes que solo necesitas hacer algo cuando la primera condición es verdadera, ya dejas 512 casos. Ese es el punto de esos controles.

Sin embargo, puede volver a escribir que sea mejor aspecto y más legible:

if(c1 && c2 && c3 && c4 && c5) 
+0

Es decir, 2 ** 10 o 1024. –

+0

@Ignacio: Quiere decir 2^10. ;) – Bobby

+2

@Bobby: los programadores inteligentes saben que 2^10 es igual a 8; P –

1

mayoría de los buenos analizadores de código estático tienen un nivel máximo de sangría por esta razón exacta. Resulta muy difícil manejar todos los casos lógicos con niveles tan altos de anidación.

¿Es este el error típico de un principiante al verificar todas las condiciones de error en un gran bulto en la parte superior de una función?

En caso afirmativo, es posible que desee obtener el autor del código para cambiarlo a una secuencia de sentencias if en lugar de esta construcción fuertemente anidada.

if(error1) { 
    /* report error 1 and exit */ 
} 

if(error2) { 
    /* report error 2 and exit */ 
} 

if(error3) { 
    /* report error 3 and exit */ 
} 

... 

hace que sea mucho más fácil para probar el código y también para proporcionar información personalizada acerca de un error específico en lugar de un "mal de algo" declaración genérica.

+0

Hace que sea más difícil refactorizar si hay varias declaraciones de devolución ... – cjk

+0

@ck, para nada si la intención de las declaraciones de devolución es clara, como en seis declaraciones de devolución en una función. Cinco en la parte superior para casos de error individuales y uno en la parte inferior para un buen resultado. Sin embargo, tener instrucciones de devolución dribladas alrededor de una función devolviendo cosas diferentes * es * definitivamente un problema para refactorizar! –

0

A lo sumo 2^10 = 1024 caminos (el máximo se alcanza si las condiciones son totalmente independientes)

Tener muchos caminos en un método se llama que tiene una alta complejidad. Esta alta complejidad impacta en la mantenibilidad y en la capacidad de prueba. Obviamente, los métodos complejos son más propensos a errores y más difíciles de probar y mantener.

La complejidad no es necesariamente un problema: algunas soluciones a los problemas tienen una complejidad inherente que no se puede eliminar. En otras palabras, algunos problemas tienen soluciones definitivamente difíciles de encontrar. En estos casos, puede reducir la complejidad local dividiendo los métodos complejos en otros más pequeños (esto no reduce la complejidad global, obviamente).

En los demás casos, eliminar la complejidad adicional: encontrar una solución más simple (fácil de decir, lo sé) ;-)

Cuestiones relacionadas