¿Cuál es la mejor opción?

Question

procedure MyProc(Eval: Boolean); 
begin  
    if not Eval then 
     Exit; 
    /* do stuff */ 
    /* do more stuff */ 
end; 

O

procedure MyProc(Eval: Boolean); 
begin 
    if Eval then 
     begin 
     /* do stuff */ 
     /* do more stuff */ 
     end; 

    /* no Exit needed, but now we got what I think unpleasing code: 
    having a indentation level and a begin-end statement */ 
end; 

Answer 1

¿Puedo alegar que si utiliza el segundo formulario, no agrega un nivel de sangría gratuito? Así insrtead de:

procedure MyProc(Eval: Boolean); 
begin 
    if Eval then 
     begin 
     /* do stuff */ 
     /* do more stuff */ 
     end; 

    /* no Exit needed, but now we got what I think unpleasing code: 
    having a indentation level and a begin-end statement */ 
end; 

dicen:

procedure MyProc(Eval: Boolean); 
begin 
    if Eval then 
    begin 
     /* do stuff */ 
     /* do more stuff */ 
    end; 

    /* no Exit needed, but now we got what I think unpleasing code: 
    having a indentation level and a begin-end statement */ 
end; 

Answer 2

hay casos en que cualquiera de los métodos es apropiado. Típicamente, sin embargo, el primero ofrece un código más legible y un mejor flujo de control. No estoy muy familiarizado con la programación de Delphi, pero en C# siempre trato de usar el primero cuando sea posible. Por lo que veo, no veo ninguna razón para que el enfoque sea diferente en Delphi.

por mencionar algunas de las ventajas:

• No hay necesidad de sangrar código subsiguiente.
• Más fácil de extender a múltiples condiciones. (Sólo tiene que añadir adicional si los estados en lugar de operadores lógicos, lo que hace las cosas más claras de la OMI.)
• La idea de que está "optar por" del método en lugar de optar en es estéticamente más agradable, ya que el siguiente código debe ser ejecutado en el caso "normal".

Aún así, hay situaciones donde la segunda opción es más apropiada. En particular, cuando el método debe dividirse en subsecciones (aunque esto a menudo es una señal de que necesita refactorizar).

Answer 3

Creo que esto es una cuestión de preferencia. Sin embargo, si tiene una serie de comprobaciones que debe realizar antes de realizar el "trabajo real", entonces la primera forma (IMO) se ve más ordenada y es más fácil seguir el flujo. Por ejemplo:

procedure MyProc(Eval: Boolean); 
begin 
    if not Eval then 
     Exit; 
    if not Eval2 then 
     Exit; 
    /* do stuff */ 
    /* do more stuff */ 
end; 

v.s.

procedure MyProc(Eval: Boolean); 
begin 
    if Eval then 
    begin 
     if Eval2 then 
     begin 
      /* do stuff */ 
      /* do more stuff */ 
     end; 
    end; 
end; 

Answer 4

Hay los que argumentan que sólo debe tener un punto de salida en su función, pero no estoy en ese campo.

Suelo utilizar múltiples devoluciones y que no afecta a la legibilidad de las funciones corto bien pensadas así que diría que ir a por lo que cree que es el más fácil de leer.

He tenido gente refactorizar código que he escrito para seguir las "reglas" y casi siempre de Terminé con una ciénaga de código ilegible debido principalmente a la sangría excesiva. Deberían haberlo dejado o haberlo hecho correctamente, dividiéndolo en más funciones.

Una molestia en particular que veo es la talla de la "else" en:

if (some condition) 
    return false; 
else 
    keep going; 

¿Creen que el flujo de control de alguna manera va a escapar de la cláusula "then"?

Answer 5

Uso la primera forma mucho. Es una programación literal de precondiciones, especialmente porque cuando el código se inserta entre las comprobaciones reales en el segundo ejemplo, las condiciones exactas son menos claras.

Trato de limitar el uso de EXIT a la primera condición, compruebe parte del procedimiento, para evitar demasiados espaguetis, pero creo que la primera forma es más limpia que los aros para saltar y preservar ese punto de salida.

Y parece que se usa mucho, teniendo en cuenta el hecho de que la salida (returnvalue) se añadió en D2009 (y FPC tenerlo durante una década)

Answer 6

La realidad es que esto es demasiado simple ejemplo para prevaricar en . Elegirá su enfoque de acuerdo con su convención existente, y este ejemplo es demasiado directo para tomar una decisión sobre la convención. Lo que es más interesante es qué hacer con las múltiples opciones de get-out-now y las declaraciones IF anidadas: es un área gris real.

¿Cuál es mi convención? Ah ... soy pragmático, no tengo reglas. Si es posible saltar por la ventana en las primeras líneas, lo tomo, porque no tengo que recordar cada vez que edito el código que alguna "llamada a función no correspondida" podría estar activa en cualquier momento durante la función.

Con el tiempo, esta función será moldeada y amasada por errores y mejoras. Es más probable que presente un nuevo error con este último enfoque que el anterior, porque la salida rápida es obvia al principio, en su cara, y no necesita preocuparse por eso "olvidado" 50 líneas de la función . En mi experiencia de introducción de errores, por supuesto.

Esta es una llamada más difícil si configura las cosas y tiene que derribarlas, ya que saltar puede obligarlo a hacer malabares con 17 estados de Schrodinger en su cabeza al hacer cambios.

Answer 7

En mi opinión, tampoco es la respuesta correcta.

La solución correcta sería incluir solo las partes "hacer cosas" y "hacer más cosas" en el procedimiento. A continuación, ajuste la llamada a procedimiento en una instrucción if, solo llamándola cuando sea necesario.

Si, como dices en tu comentario, que "hacer cosas" y "hacer más cosas" cubren dos dominios diferentes, entonces tal vez quieras dos procedimientos: uno para "hacer cosas" y otro para "hacer más cosas" . Si realiza los dos procedimientos juntos lo suficiente, también puede incluir un tercer procedimiento que simplemente llame a los otros dos procedimientos.

Answer 8

creo que los puntos de salida menos un segmento de código tiene el mejor por lo que es más fácil de leer y entender. Observar es peor que depurar la función de 100 líneas de otra persona y descubrir que hay 12 situaciones diferentes salpicadas en su interior que pueden hacer que vuelva temprano.

Answer 9

Prefiero:

if not Eval then Exit; 

porque el código es el más limpio de esa manera.