c# - simples - if anidado c++
Control de flujo a través de retorno vs. Si/Else (12)
Cuál es mejor (flujo de control implícito a través de retorno o flujo de control a través de si ) - vea a continuación. Por favor explique lo que ve como ventaja / desventaja a cualquiera de los dos. Me gusta la opción A porque es menos código.
Flujo por retorno:
public ActionResult Edit(MyClass class)
{
if (!class.Editable)
return null;
class.Update();
return View();
}
Flujo a través de Si / Else:
public ActionResult Edit(MyClass class)
{
if (class.Editable)
{
class.Update();
return View();
}
else
{
return null;
}
}
Ambas declaraciones controlan el flujo a través de una instrucción if . Es solo una cuestión de cómo manejar la condición.
Siempre estoy en la valla cuando se trata de escribir declaraciones lógicas como esta. A una parte de mí le gusta la primera opción porque es un poco menos de código. A la otra parte le gusta la segunda opción porque es mucho más fácil seguir el flujo de la lógica. Con la primera opción, es fácil perder la declaración de devolución que puede llevar a problemas de administración en el futuro.
... y por esa razón, la segunda opción siempre gana en mi libro. Es mejor escribir código que sea más fácil de leer y mantener que tratar de tomar atajos.
Ambas son opciones válidas, y una no es necesariamente mejor que la otra. La que elija es, en última instancia, la preferencia personal. Sí, la Opción A produce un código ligeramente menor, pero en general son bastante iguales.
En ambos casos, usted está controlando el flujo a través de un if y un retorno. Es realmente una cuestión de cómo prefiere ver su lógica booleana, ¿negativa o positiva?
¿Es ActionResult una enumeración o una clase base? Si se trata de una enumeración, ¿por qué devuelve null cuando Edit devuelve lo que parece ser una enumeración? ¿No sería más limpio simplemente devolver un valor ActionResult que indica que no se realizó ninguna acción porque el objeto no estaba en un estado editable?
La primera opción, usar return, es mejor, porque:
- tienes un lugar para poner todos los guardias y condiciones previas, cerca de tus afirmaciones y todas esas cosas.
- para mí, es más fácil pensar "veamos todo lo que puede estar mal, y regresemos. Desde este punto, tengo todo lo que necesito y estoy en el Sendero Feliz.
- Si utiliza el enfoque if / else, tiene todo el código en ese método / función con sangría. Agrega otro si, o para, y las cosas empiezan a ponerse divertidas.
Un defensor de este método (retorno) es Marcus Zarra , en el estilo de codificación Cocoa is my Girlfriend.
No hay mucha diferencia en este ejemplo específico, pero en general me gusta el primer enfoque porque usa una cláusula de guardia para regresar temprano. Si comienza a agregar condiciones anidadas al segundo enfoque, verá que la legibilidad de su código se verá afectada. Las cláusulas de protección pueden contribuir en gran medida a reducir la profundidad de anidamiento y mejorar la legibilidad de su código.
Personalmente me gusta el enfoque if/else . Por un lado, su declaración if es positiva, no negativa, lo que facilita su lectura. Para dos, has resumido las condiciones entre paréntesis, y soy un fan de ese estilo.
De todos modos, es mucho más fácil seguir lo que está pasando en el segundo que en el primero. Y eso siempre gana en mi libro.
Preferiría que identifiqué como el que EJECUTA menos código.
Si es más común en clase. Editable siendo falso, entonces iría por A.
Pero este ejemplo no da mucha ventaja en ninguno de los dos casos.
En cualquier situación dada, un desarrollador debe analizar la entrada y ajustar el código para ser optimizado en los datos de entrada más comunes.
EDITAR:
Para aclarar:
Al ejecutar menos código lo que en realidad quiero decir es más eficiente ...
Prefiero el segundo enfoque en aras de la legibilidad y el mantenimiento. La legibilidad porque solo me dice "más limpio" que el primer enfoque, y la capacidad de mantenimiento porque no tengo que preocuparme por agregar llaves si necesito modificar las cláusulas if o else. Además, el primer enfoque es solo 7 caracteres menos que el segundo si no incluye nuevas líneas, lo que no parece ser una justificación para elegir el primero en lugar del segundo.
Dicho esto, en realidad prefiero esto:
public ActionResult Edit(MyClass class)
{
ActionResult rv = null;
if (class.Editable)
{
class.Update();
rv = View();
}
return rv;
}
Es más código, pero ahora puedo establecer un único punto de interrupción en la declaración de devolución para inspeccionar el valor que se devuelve en lugar de tener que establecer dos puntos de interrupción para hacer lo mismo en las dos opciones que ofreció.
Prefiero la primera opción, siempre que el caso que verifique sea una condición de guardia / precondición que deba cumplirse para que la llamada al método sea válida. Aunque podría discutir si debería devolver un valor nulo, o lanzar una Excepción (Argumento). Cuando una clase no es editable, ¿debería ser realmente un parámetro para este método?
Tal vez una mejor opción sería crear una interfaz editable con IE e implementarla en la clase de la que está pasando una instancia ahora mismo.
Salga temprano: prefiero ver todas las condiciones que harán que el método salga sin hacer mucho por adelantado. Evito las declaraciones de otro tipo si puedo evitarlo.
Esta es en realidad una escuela de pensamiento bastante prominente entre la multitud de contratos de código.
También prefiero la opción 1. Para mí, se lee mejor como un libro. También me duele siempre que no haya una devolución al final de la opción 2.
Yo prefiero if/else , también. La legibilidad, la legibilidad y la capacidad de mantenimiento están por encima de cualquier otra cosa, para mí.
bajo estas circunstancias, me gustaría ir con la opción A. En este caso, está haciendo su validación de entrada y luego impide la ejecución del resto del código si la entrada no es válida (no editable). Esto mantiene a todo el cuerpo de la función fuera de una gran declaración if / else y la hace más legible.
Sin embargo, también consideraría plantear una excepción en lugar de volver a sintonizar un valor nulo, es decir, suponer que pasar un objeto no editable a una función de "edición" no es algo normal.