primeros resultados positivos frente a anidar sentencias if

aquí tienes hipotético ejemplo de código:primeros resultados positivos frente a anidar sentencias if

if (e.KeyCode == Keys.Enter) 
{ 
    if (this.CurrentElement == null) { 
     return false;} 

    if (this.CurrentElement == this.MasterElement) { 
     return false;} 

    if (!Validator.Exist (this.CurrentElement)) { 
     return false;} 

    if (!Identifier.IsPictureElement (this.CurrentElement)) { 
     return false;} 

    this.FlattenObjects(this.CurrentElement); 
}

if (e.KeyCode == Keys.Enter) 
{ 
    if (this.CurrentElement != null) { 

     if (this.CurrentElement != this.MasterElement) { 

      if (Validator.Exist (this.CurrentElement)) { 

       if (Identifier.IsPictureElement (this.CurrentElement)) { 

        this.FlattenObjects(this.CurrentElement);}}}}}} 

}

Cuál cree usted que es mejor en términos de facilidad de lectura, mantenimiento, etc.?

También el segundo ejemplo se puede formatear de forma diferente mediante el uso diferente de paréntesis.

Fuente

2010-12-06 Joan Venge

+18

Ese es uno de los peores estilos de corsé que he visto en mi vida. – SLaks

Hehe, realmente vi un código real como ese. Pero lamento haberme apresurado a escribirlo así, se vería mejor con el horquillado correcto. –

http://stackoverflow.com/questions/237719/what-is-the-most-frustrating-programming-style-youve-encountered/930831#930831 – SLaks

Las devoluciones anticipadas son mucho más legibles.

Cada vez que obtenga más de cuatro o cinco niveles de anidación dentro de un método, es hora de refactorizar ese método.

Una sola if con una cláusula || a veces puede ser más fácil de leer:

if (this.CurrentElement == null 
|| this.CurrentElement == this.MasterElement 
|| !Validator.Exist(this.CurrentElement) 
|| !Identifier.IsPictureElement(this.CurrentElement)) 
    return false;

Fuente

2010-12-06 18:49:07 SLaks

Gracias, es un estilo interesante. Pero, ¿cómo lo formatearías con 4-5 niveles de anidación, lo que significa 4-5 controles, ¿verdad? Entonces, el método anterior, ¿lo refactorizaría, en términos de dividirlo en diferentes métodos? –

@Joan: depende completamente del código. Sin embargo, es posible que desee crear un método separado que haga toda la verificación y devuelva 'true' o' false'. – SLaks

Gracias, lo tengo. Es solo que a veces, obtienes estos casos únicos e independientes que requieren muchos controles, pero no se pueden combinar fácilmente en menos métodos, pero entiendo a qué te refieres. –

Creo que lo escribiría como:

if (this.CurrentElement == null OR this.CurrentElement == this.MasterElement OR ...) return false;

Fuente

2010-12-06 18:49:58 PeeHaa

Yo también, pero en varias líneas y con la sintaxis correcta. – SLaks

Ony con nuevas líneas? –

Gracias, pero cuando hago eso, las líneas a veces son muy largas, digamos con 6 comprobaciones. –

El primer ejemplo es mejor en todos los sentidos. Es más simple y más fácil de leer. Algunas personas dicen que cada función debe tener un único punto de retorno; este ejemplo muestra claramente por qué esas personas están equivocadas.

PS Personalmente eliminaría todas esas llaves superfluos:

if (this.CurrentElement == null) return false;

etc. Esto hace que sea aún más simple, y aún más fácil de leer.

Fuente

2010-12-06 18:52:18 TonyK

Creo que la mayoría de la gente tiene una idea equivocada de entrada única/salida única - vea [esta publicación] (http://softwareengineering.stackexchange.com/a/118793) – andreee

Yo diría que el primero es mejor para la legibilidad y el mantenimiento. Sin embargo, probablemente escribiría algo como esto.

if (e.KeyCode == Keys.Enter) { 
    if(this.CurrentElement == null || 
     this.CurrentElement == this.MasterElement || 
     !validator.exists(this.CurrentElement) || 
     !identifier.isPictureElement(this.CurrentElement)) 
    { 
     return false; 
    { 
    else 
    { 
     this.flattenObjects(this.CurrentElement); 
    } 
}

Fuente

2010-12-06 18:54:19 OrangeDog

Gracias pero no son clases, se supone que los métodos son PascalCase? –

Estaba asumiendo Java, y ese validador/identificador eran objetos. – OrangeDog

Ok, veo lo que quieres decir. Sí, siempre estoy pensando en el modo C#/.NET, pero esta técnica sigue siendo válida, por supuesto. –

Teniendo en cuenta que en el segundo ejemplo "falsa" es el cambio de todos los caminos, pero es más implícito que declarada por qué no acaba de hacer todas las declaraciones implícitamente falso y simplemente probar la condición de que uno es único?

Esto puede violar las pautas de estilo de alguien, pero lógicamente es el más breve.

if(e.KeyCode == Keys.Enter 
&& this.CurrentElement != null 
&& this.CurrentElement != this.MasterElement 
&& Validator.Exist (this.CurrentElement)      
&& Identifier.IsPictureElement (this.CurrentElement)) 
    this.FlattenObjects(this.CurrentElement);

Fuente

2016-11-21 17:40:57

primeros resultados positivos frente a anidar sentencias if

Respuesta

Cuestiones relacionadas