JavaScript condición de bloqueo vs declaración en blanco para el flujo de control

Question

siempre he escrito mis bloques de JavaScript

var functionName = function() { 
    if (someCondition) { 
     // stuff 
    } else { 
     // stuff 
    } 
}; 

pero hoy vi

var functionName = function() { 
    if (someCondition) { 
    // stuff 
    return; 
    } 
    // stuff 
}; 

Me gusta que el primer ejemplo es más explícito en la lógica. ¿Cuáles son algunas de las razones por las que querría o no querría hacerlo de la segunda manera demostrada?

Answer 1

Menos indentación en caso de que tenga más de un someCondition.

Imagínese:

var functionName = function() { 
    if (someCondition) { 
     // stuff 
    } else { 
     // stuff 
     if (someConditionB) { 
      // stuff 

     } else { 
      // stuff 

      if (someConditionC) { 
       // stuff 

      } else { 
       // stuff 

       if (someConditionD) { 
        // stuff 
       } else { 
        // stuff 
       } 
      } 
     } 
    } 
}; 

que sería mucho más fácil de leer, sin todo el vigilara:

var functionName = function() { 
    if (someCondition) { 
     // stuff 
     return; 
    } 

    if (someConditionB) { 
     // stuff 
     return; 
    } 

    if (someConditionC) { 
     // stuff 
     return; 
    } 
    if (someConditionD) { 
     // stuff 
     return; 
    } 

    // stuff 
}; 

Answer 2

Es posible que desee utilizar el método 2 en 2 casos:

Caso 1: tiene muchas cosas después de su lógica que usted no quiere correr. El código ejecutado hace todo lo que necesita y no necesita las cosas adicionales.

Caso 2: Dependiendo de a qué función esté asociada, desea devolver un mensaje falso para evitar una acción. Una vez que tal instancia sería un onSubmit para un formulario, y valide la entrada. Si es malo, devuelva inmediatamente false y evite que se envíe el formulario.

Answer 3

Muchos codificación de las normas exigen que usted no debe "retirada prematura" de funciones. Es una compensación entre la legibilidad y la "corrección" [*]

La salida anticipada evita la necesidad de que el código subsiguiente se sangre en un nivel extra. Por ejemplo, en mi humilde opinión, tiene sentido tener algunas comprobaciones de detección de errores agrupadas juntas en la parte superior de las funciones con una salida temprana en caso de falla, con el contenido de la función escrito de forma normal.

Por otro lado, al leer el código con fines de depuración, es fácil pasar por alto la salida anticipada, y terminar tratando de encontrar un error en la parte incorrecta de su código.

[*] esos mismos estándares de código a menudo evitan el uso de break y continue. FWIW Creo que es un síntoma de la aplicación excesiva del mantra "GOTO considerado dañino" de Djikstra.