¿Cuál es el mejor estilo de codificación?

Question

Durante una revisión del código, un desarrollador sénior comentó sobre el anidamiento que tenía en mi código. Sugirió que establezca un valor de bool para que nunca tenga más de un nivel de anidación. Creo que mi código es más legible pero quiero obtener la opinión de otros desarrolladores sobre esto. ¿Cuál es mejor estilo? ¿Se fundó su aversión instintiva a la anidación?

A continuación se muestran algunos ejemplos de código simplificado.

anidada:

If(condition1) 
{ 
    If(condition2) 
    { 
     if(condition3) 
     { 
      return true; 
     } 
     else 
     { 
      log("condition3 failed"); 
     } 
    else 
    { 
     log("condition2 failed") 
    } 
} 
else 
{ 
    log("condition1 failed") 
} 

return false; 

o

Bool Driven:

bool bRC = false; 

bRC = (condition1); 
if(brc) 
{ 
    bRC = (condition2); 
} 
else 
{ 
    log("condition1 failed"); 
    return false; 
} 

if(bRC) 
{ 
    bRC = (condition3); 
} 
else 
{ 
    log("condition2 failed"); 
    return false; 
} 

if(bRC) 
{ 
    return true; 
} 
else 
{ 
    log("condition3 failed"); 
    return false; 
} 

Answer 1

I como la suya mejor, pero probablemente haría algo como:

if (condition1 && condition2 && condition3) 
{ 
    return true; 
} 
else if (!condition1) 
{ 
    log("condition1 failed"); 
} 
else if (!condition2) 
{ 
    log("condition2 failed"); 
} 
else 
{ 
    log("condition3 failed"); 
} 
return false; 

Si las condiciones son expresiones complejas entonces podría asignar las expresiones a denominarse adecuadamente las variables antes de evaluar el if para evitar tener que recalcula los valores en cada if.

Esto supone que el modo normal es que todas las condiciones son verdaderas y, por lo tanto, desea tener esa verificación primero. Si el modo normal es que una o más condiciones son falsas, entonces lo reordenaré y verificaré cada negación a la vez y simplemente devolveré verdadero si todas las comprobaciones fallaron. Eso también eliminaría la necesidad de variables temporales para tomar el lugar de expresiones complejas.

Answer 2

generalmente prefiero jerarquizadas por mis condiciones; por supuesto, si mis condiciones anidadas se sangran demasiado a la derecha, tengo que empezar a preguntarme si hay una mejor manera de hacer lo que estoy intentando (refactorización, rediseño, etc.)

Answer 3

I personalmente encuentre el código anidado significativamente más fácil de leer.

Answer 4

El segundo estilo es absurdamente detallado: ¿realmente sugirió exactamente esto? No necesita la mayoría de esas declaraciones if, porque hay un return en la parte else.

Con el ejemplo anidado confía en no omitir incluir cualquier posible cláusula else.

Ninguno de estos me parece satisfactorio.

Answer 5

El camino impulsado por bool es confuso. El anidamiento está bien si es necesario, pero puede eliminar parte de la profundidad de anidamiento combinando las condiciones en una declaración, o llamando a un método donde se realiza parte de la evaluación adicional.

Answer 6

El código debe replantear el problema en un idioma dado. Por lo tanto, mantengo que cualquiera de los fragmentos puede ser "mejor". Depende del problema que se modele. Aunque creo que ninguna de las soluciones será paralela al problema real. Si pone términos reales en lugar de condition1,2,3 podría cambiar completamente el "mejor" código.
Sospecho que hay una mejor manera (3d) de escribir todo eso juntos.

Answer 7

Creo que ambas formas son posibles y tienen sus pros y contras. Usaría el estilo impulsado por bool en casos en los que tendría una anidación realmente profunda (8 o 10 o algo así).En su caso con 3 niveles, elegiría a su estilo, pero para la muestra exacta de lo alto, me iría así:

 
void YourMethod(...) 
{ 
    if (condition1 && condition2 && consition3) 
    return true; 

    if (!condition 1) 
    log("condition 1 failed"); 

    if (!condition 2) 
    log("condition 2 failed"); 

    if (!condition 3) 
    log("condition 3 failed"); 

    return result; 
} 

... o gustaría que si usted prefiere un sólo punto de salida (como hago) ...

 
void YourMethod(...) 
{ 
    bool result = false; 

    if (condition1 && condition2 && consition3) 
    { 
    result = true; 
    } 
    else 
    { 
    if (!condition 1) 
     log("condition 1 failed"); 

    if (!condition 2) 
     log("condition 2 failed"); 

    if (!condition 3) 
     log("condition 3 failed"); 
    } 
    return result; 
} 

esta manera, usted recibirá toda la condición de fallo conectado a la primera carrera. En su ejemplo, obtendrá solo una condición fallida registrada incluso si hay más de una condición anómala.

Answer 8

probablemente me voy con

if (!condition1)  log("condition 1 failed"); 
    else if (!condition2) log("condition 2 failed"); 
    else if (!condition3) log("condition 3 failed"); 
    // ------------------------------------------- 
    return condition1 && condition2 && condition3; 

que creo que es mucho más limpio y equivilent ...

Además, una vez que el cliente decide que todas las condiciones deben ser evaluados y registrados si fallan, no sólo el primero que falla, esto es mucho más fácil de modificar para hacerlo:

if (!condition1) log("condition 1 failed"); 
    if (!condition2) log("condition 2 failed"); 
    if (!condition3) log("condition 3 failed"); 
    // ------------------------------------------- 
    return condition1 && condition2 && condition3; 

Answer 9

Si el idioma es compatible con el manejo de excepciones, me gustaría ir con lo siguiente:

try { 
    if (!condition1) { 
     throw "condition1 failed"; 
    } 

    if (!condition2) { 
     throw "condition2 failed"; 
    } 

    if (!condition3) { 
     throw "condition3 failed"; 
    } 

    return true; 

} catch (e) { 
    log(e); 
    return false; 
} 

EDITAR de Charles Bretana: Por favor, vea Using Exceptions for control flow

Answer 10

Si usted no tiene ningún reglas tontas sobre múltiples puntos de retorno, creo que esto es bastante agradable (y lo mismo ocurre con otra persona, pero su borrado respuesta por razones desconocidas):

if(!condition1) 
{ 
    log("condition1 failed"); 
    return false; 
} 

if(!condition2) 
{ 
    log("condition2 failed"); 
    return false; 
} 

if(!condition3) 
{ 
    log("condition3 failed"); 
    return false; 
} 

return true; 

Tal vez este es un igual aversión instintiva a super-anidación, pero es sin duda más limpio que su basura almacenar las condiciones booleanas en ciertos valores. Sin embargo, puede ser menos legible en contexto: considere si una de las condiciones fue isreadable(). Es más claro decir if(isreadable()) porque queremos saber si algo es legible. if(!isreadable()) sugiere si queremos saber si no es legible, lo cual no es nuestra intención. Ciertamente es discutible que haya situaciones en las que uno es más legible/intuitivo que el otro, pero yo también soy un fan de esta manera. Si alguien se colgó en las declaraciones, usted podría hacer esto:

if(!condition1) 
    log("condition1 failed"); 

else if(!condition2) 
    log("condition2 failed"); 

else if(!condition3) 
    log("condition3 failed"); 

else 
    return true; 

return false; 

Pero eso es más bien solapada, y menos "claro" en mi opinión.

Answer 11

Así es como lo implementaría, siempre que sus implementaciones realmente reflejen el comportamiento deseado.

if (!condition1) { 
    log("condition1 failed"); 
    return false; 
} 
if (!condition2) { 
    log("condition2 failed"); 
    return false; 
} 
if (!condition3) { 
    log("condition3 failed"); 
    return false; 
} 
return true; 

Sin embargo, creo que es más probable que todas las condiciones fallidas se registren.

result = true; 
if (!condition1) { 
    log("condition1 failed"); 
    result = false; 
} 
if (!condition2) { 
    log("condition2 failed"); 
    result = false; 
} 
if (!condition3) { 
    log("condition3 failed"); 
    result = false; 
} 
return result; 

Answer 12

Al igual que en la versión anidada, pero mucho más limpio para mí:

if not condition1: 
    log("condition 1 failed") 
else if not condition2: 
    log("condition 2 failed") 
else if not condition3: 
    log("condition 3 failed") 
else 
    return true; 
return false; 

Tenga en cuenta que cada condición se evalúa una vez.

Answer 13

No me gusta de ninguna manera. Cuando tienes tantos nidos, algo está mal. En el caso de una validación de formulario o algo que realmente requiera algo como esto, intente descubrir algo que sea más modular o compacto.

Un ejemplo sería una matriz que contiene las condiciones, a través de la cual podrá iterar por un tiempo, e imprimir/romper según sea necesario.

Existen demasiadas implementaciones según sus necesidades, por lo que crear un código de ejemplo no tendría sentido.

Como regla general, cuando su código parece demasiado complicado, apesta :). Intenta reconsiderarlo. Seguir las prácticas de codificación la mayoría de las veces hace que el código resulte mucho más estético y corto; y obviamente, también más inteligente.

Answer 14

if(condition1 && condition2 && condition3) 
    return true; 

log(String.Format("{0} failed", !condition1 ? "condition1" : (!condition2 ? "condition2" : "condition3"))); 
return false; 

De esta manera, no tiene que ver muchas líneas de código solo para iniciar sesión. Y si todas sus condiciones son ciertas, no pierda el tiempo evaluándolas en caso de que tenga que iniciar sesión.