La pregunta que hice podría cerrarse. Pero solo quiero saber que es necesario escribir otra parte de cada condición. Uno de mis programadores senior me dijo que "debes escribir else else en cada condición si". Supongamos que no tenemos ninguna condición para escribir en la parte else, entonces ¿qué deberíamos hacer? Asumo una discusión sana pasando aquí ....¿Es necesario escribir parte else en cada condición if?
, gracias & Saludos, Rahul Vyas
Esa es una idea horrible. Se termina con código del formulario:
if (something) {
doSomething();
} else {
}
cómo alguien puede pensar que es más fácil de leer o mantenible que el no tener un else en absoluto es más allá. Suena como una de esas reglas compuestas por personas que tienen demasiado tiempo libre en sus manos. Conseguir que dispararon tan pronto como sea posible, o al menos se alejan con calma y tranquilidad :-)
No, usted no tiene que ..
Además, no creo que es una buena idea para la legibilidad, ya que tendrá muchos bloques vacíos else. que no será bonito de ver
¡Peligro! Peligro, Will Robinson!
http://en.wikipedia.org/wiki/Cargo_cult_programming
es la inclusión de vacíos else { } bloques que van a mejorar de alguna manera la calidad, la facilidad de lectura, o la robustez de su código? Yo creo que no.
No, pero yo personalmente eligen siempre incluyen la encapsulación de los frenos para evitar
if (someCondition)
bar();
notbar(); //won't be run conditionally, though it looks like it might
foo();
me gustaría escribir
if (someCondition){
bar();
notbar(); //will be run
}
foo();
No, usted ciertamente no tiene tiene - al menos en la mayoría de los idiomas. (. No se ha especificado, es muy posible que hay un lenguaje que qué hacer cumplir este) He aquí un ejemplo en el que sin duda no:
public void DoSomething(string text)
{
if (text == null)
{
throw new ArgumentNullException("text");
}
// Do stuff
}
Ahora podría poner el trabajo principal de la método en una cláusula "else" aquí, pero aumentaría la anidación innecesariamente. Agregue algunas condiciones más y todo se convierte en un desastre ilegible.
Este patrón de "salida anticipada" es razonablemente común, en mi experiencia, y va para los valores de devolución, así como para las excepciones. Sé que hay algunos que están a favor de un único punto de retorno de un método, pero en los idiomas con los que trabajo (Java, C#) que a menudo pueden conducir a un código mucho menos legible y una anidación más profunda.
Ahora, hay una situación en la que hay más margen para el debate, y ahí es donde las dos ramas son terminales, pero ninguno de ellos es efectivamente un acceso directo:
public int DoSomething()
{
// Do some work
if (conditionBasedOnPreviousWork)
{
log.Info("Condition met; returning discount");
return discount;
}
else
{
log.Info("Condition not met; returning original price");
return originalPrice;
}
}
(Tenga en cuenta que me he dado deliberadamente ambas ramas más trabajo por hacer que solo regresar; de lo contrario, una declaración condicional sería apropiada.)
¿Sería esto más legible sin el "else"? Esa es realmente una cuestión de elección personal, y no voy a decir que siempre soy consecuente. Tener ambas ramas igualmente sangradas les otorga el mismo peso de alguna manera, y tal vez fomenta la posibilidad de refactorizar más tarde invirtiendo la condición ... mientras que si acabáramos de obtener el "precio original de devolución", la refactorización de poner ese en si bloquea y mueve el caso de descuento fuera de un bloque if sería menos obviamente correcto a primera vista.
A veces no hay ninguna otra parte ... e incluir una vacía simplemente hace que el código sea menos legible.
Esto es puramente una cuestión de estilo y claridad. Es fácil imaginar declaraciones, particularmente simples, para las cuales otro sería completamente superfluo. Pero cuando tienes un condicional más complejo, tal vez manejando una cantidad de varios casos, a menudo puede ser esclarecedor declarar explícitamente que de lo contrario, no se debería hacer nada. En estos casos, dejaría un comentario de // do nothing en el otro lado vacío para aclarar que el espacio se dejó en blanco intencionalmente.
En lenguajes imperativos como Java y C, if - else es una afirmación y no devuelve ningún valor. Para que pueda escribir solo la parte if y continuar. Y creo que es la mejor práctica en lugar de agregar else s vacíos después de cada if.
Sin embargo, en lenguajes funcionales como Haskell y Clojure, if es una expresión y debe devolver un valor. Por lo tanto, debe tener éxito con un else. Sin embargo, aún hay casos en los que es posible que no necesite una sección else. Clojure, para tales casos, tiene una macro when que envuelve if - else para devolver nil en la sección else y evita escribirla.
(when (met? somecondition)
(dosomething))
+1 por ser la única respuesta para mencionar el 'if-else' _expression_. – missingfaktor
En cuanto a este puramente desde un punto de vista semántico - No puedo pensar en un solo caso donde no hay una cosa implícita para cada caso.
si el automóvil no se detiene antes de llegar al muro, chocaré, de lo contrario no chocaré.
Semántica aparte:
La respuesta a esta pregunta depende del entorno, y lo que el resultado de un error es.
¿Código comercial? Haz lo que dicen tus estándares de codificación.
En mi humilde opinión, encontrará que deletrearlo, aunque inicialmente parece demasiado trabajo, será invaluable en 10 años a partir de ahora cuando vuelva a visitar ese código. Pero, ciertamente, no sería el fin del mundo si te perdieras una importante 'anti condición'.
Sin embargo: ¿Código de seguridad, de seguridad o de vida crítica? Esa es una historia diferente.
En este caso, desea hacer dos cosas.
En primer lugar: en lugar de probar una falla, quiere probar que hay no una falla. Esto requiere una vista pesimista sobre la entrada a cualquier módulo. Usted asume que todo está mal hasta que demuestre que es correcto.
Segundo: en la vida crítica: NUNCA quiere lastimar a un paciente.:
bool everyThingIsSafe = true;
if(darnThereIsAProblem())
{
reportToUserEndOfWorld();
}
return everyThingIsSafe;
Oops. Olvidé configurar everyThingIsSafe como falso.
La rutina que llamó a este snippit ahora se le mintió. Si hubiera inicializado evertThingIsSafe en falso, siempre estoy a salvo, pero ahora necesito la cláusula else para indicar que no hubo un error.
Y sí, podría haber cambiado esto a una prueba positiva, pero entonces necesito el para manejar el error.
Y sí, podría haber asignado everyThingIsSafe() la devolución inmediata del cheque. Y luego probó la bandera para informar un problema. Un otro implícito, ¿por qué no ser explícito?
Estrictamente hablando, lo implícito que esto representa es razonable.
Para un auditor de seguridad/FDA, tal vez no.
Si es explícito, puede apuntar a la prueba, es lo contrario, y que manejé ambas condiciones con claridad.
He estado codificando dispositivos médicos durante 25 años. En este caso, quiere el otro, quiere el valor predeterminado en el caso, y nunca están vacíos. Desea saber exactamente qué va a suceder o lo más cerca posible. Porque pasar por alto una condición podría matar a alguien.
Busque Therac-25. 8 gravemente herido. 3 muertos.
Sé que llego tarde pero pensé un montón sobre esto y quería compartir mis resultados.
En el código crítico, es imprescindible para cada rama se cuenta. Escribir un else no es necesario, pero deje una marca que indique que no es necesario y por qué. Esto ayudará al revisor. Observe:
//negatives should be fixed
if(a < 0) {
a+=m;
}
//else value is positive
Intento no "debería" en mis compañeros. Tiende a ser complicado. Use un else solo si tiene sentido. – kbrimington
"si" siempre escuchas a tus compañeros de trabajo, retomarás sus malos hábitos. No hay necesidad de decir "else", puedes aprender por ti mismo ". – Laramie
Creo que su programador senior en realidad dijo: "debería pensar en la parte else en todas las condiciones". He visto demasiadas fallas en el código debido a la falta de bloques adicionales. –