{7} Comentarios.

1. 

   josejuan

   14Oct2013/

   Puede quedar bien en muchos casos, pero en otros, sobre todo en aquellos en que precisamente los if anidados tienen sentido juntos, podría quedar incluso menos legible.

   Por ejemplo, los if anidados suelen surgir al necesitar generar un valor en base a otros intermedios (que por cuestión de rendimiento o imposibilidad no deben calcularse hasta que sea preciso).

   En tal caso (no se como se verá el código…) se vería algo como:

   var r, a = A(r);
   if( cond(a) ) {
       var b = B(r, a);
       r = cond(b) ? R1(r, a, b) : R2(r, a);
   } else {
       var c = C(r);
       r = cond(c) ? R3(r, c) : R4(r);
   }
   

   Por otro lado, aunque no es una práctica «clean code», a mi me gusta resolver los «if / switch» como el de tu ejemplo haciendo «return», como:

   function takeValue(x...) {
     if(cond1) return result1;
     if(cond2) {
        ...
        return result2;
     }
     if(cond3) return result3;
     return defaultResult;
   }
   

   Viene a ser tu «switch» pero de otra forma, cuestión de gustos supongo 😀

   Por último, ¿no has metido el !foo en el switch por algún motivo?.

   • 

     Carlos Benítez

     14Oct2013/

     Si, para casos donde hay muchos niveles de anidación, habría que replantear alguna solución más limpia.

     El caso de los multiples ‘returns’ lo utilizo también con frecuencia dejando al igual que en tu ejemplo, un último ‘return’ para el comportamiento ‘default’ en caso de que no se cumpla nada de lo anterior. Sin embargo, si veo que meto más de tres, ya comienzo a verlo enredado y considero otras soluciones.

     En cuanto al !foo, no lo puedo incluir en el switch porque daría error si no está definido:

     console.log( !noVar ); // Error
     console.log( !!noVar ); // Error
     console.log( typeof noVar ); // "undefined"
     

     La forma de conseguir la evaluación sin que arroje error es utilizando el typeof y queda algo bizarra:

     switch ( true ) {
       case ( typeof foo === "undefined" ):
         // Foo is undefined. Do something...
         break; 
     }
     

     Ahí estaríamos sacando el tipo, evaluándolo y comprobando si realmente existe o no… me resulta feo y por eso prefiero sacarlo como una condición previa fuera incluso del switch.

     Saludos!
2. 

   acido69

   14Oct2013/

   Personalmente veo poco legible este método y si lo hacemos por el aumento de rendimiento creo que es totalmente irrisorio el aumento por rendimiento.

   Me explico por partes:

   *return*
   Personalmente creo que después de un return no debería de haber nada, encontrarte un return en las primeras líneas de una función no es estético; esto imagino que es algo muy personal. En este punto si que puede haber mucha diferencia de rendimiento dependiendo de la cantidad de operaciones innecesarias que se vayan a hacer en esa función. Pero creo que hay muchas maneras de evitar esas evaluaciones innecesarias.

   *switch*
   Si nuestra función es sólo un wrapper de otras funciones, es que algo no va bien o no hemos sabido plantear el programa. Aquí la verdad es que ya depende mucho de la estructura del programa y cada caso sería muy particular.

   Personalmente creo que el aumento de rendimiento no compensa la legibilidad de este uso. Ahora bien, puede que no me esté imaginando bien los escenarios de uso.

   Un saludo

   • 

     Carlos Benítez

     14Oct2013/

     Si; cuestión de gustos, pero no estoy de acuerdo con tu argumento del ‘return’. Personalmente no creo que tenga ser el final de una función y no dejar nada por debajo.
     De hecho, es una práctica frecuente su uso en estructuras de control para reducir precisamente complejidad:

     if ( foo === true ) {
       return true;
     }
     
     return false;
     

     Eso nos elimina un ‘else’ innecesario para el caso en que foo no se cumpla la primera igualdad. Es cierto también que para el caso anterior, donde solo hay una instrucción, un ternario quedaría más bonito:

     return ( foo === true ) ? true : false;
     

     Además de que, para evaluar a ‘true’, nos sobra el valor de la constante y el paréntesis:

     return foo ? true : false;
     

     Pero bueno, comentario interesante y, como siempre, es cuestión de gustos!!
     Saludos!
3. 

   josejuan

   14Oct2013/

   «pero no estoy de acuerdo con tu argumento del ‘return’»

   Por lo visto además de la prosa tenemos también gustos «coding» similares 😀 😀

   Los ejemplos que acabas de poner son muy de mi gusto, pero @acido69 tiene «razón» en que no son estilos «limpios» según los cánones del «clean code».

   La programación estructurada exige que sólo haya return al final de la función. Luego ya el «clean code» diría que no es recomendable poner la expresión en el return, que mejor asignar primero a una variable (no sólo porque el nombre de la variable mejoraría la lectura, también para poder depurar cómodamente, etc…).

   Pero que carajo, a mi esos códigos me parecen feos y aburridos XD XD
4. 

   juan

   17May2014/

   Hola buenas, llevo tiempo siguiendo tu blog, aunque comento mas bien poco, y observando el ultimo ejemplo hay algo que no acabo de entender con el switch que has indicado:

   switch ( true ) {
   case foo.test():
   // Do something when foo.test is true
   case foo.test2():
   // AND do something is foo.test2 is true
   default:
   // Do something when all above is false
   break;
   }
   Si el primer foo.test() es true, segun el switch, entrara en el resto de cases hasta que no encuentre un break, por lo tanto entrara en foo.test2() independientemente de que este sea true o sea false y tmb en el default.
   Si el primer foo.test() es false, si evaluara foo.test2() y solo entrara siempre y cuando este sea true, y en caso de que sea true tmb entrara en el default.
   Y en el default entrara siempre.
   Asi pues, si eliminas el break, no haces que se evalue la siguiente condicion, sino que das por validas el resto mientras no encuentres un break, incluso el default.

   O eso, o me estoy perdiendo algo xD

   Este seria un ejemplo
   switch ( 4 ) {
   case 4:
   console.log(‘igual a 4’);
   case 2:
   console.log(‘igual a 2 o 4’);
   break;
   default:
   console.log(‘diferente de 2 o 4’);
   break;
   }

   • 

     Carlos Benítez

     17May2014/

     Hola Juan; tienes toda la razón, he eliminado esa parte del artículo porque efectivamente no se comporta como había descrito.

     Gracias por tu comentario y reporte.

     Saludos!