c# - resueltos - funcion si condicional
¿Cuál es mejor aplicar dos condiciones en Anidado Si o usando solo con Y? (10)
Anidado Si o solo si con el operador Y, ¿cuál es el mejor enfoque?
Solo si con Y
if (txtPackage.Text != string.Empty && txtPackage.Text == "abc")
{
//
}
Anidado si
if (txtPackage.Text != string.Empty)
{
if (txtPackage.Text == "abc")
{
//
}
}
¿Va a hacer algo diferente en el ejemplo ''anidado si'', de hecho, txtPackage.Text no está vacío pero contiene algo más que ''abc''?
Si no lo eres, te preguntaría por qué estás buscando string.empty en absoluto?
Podrías escribir:
if (txtPackage.Text == "abc")
{
//
}
y termine con esto.
Totalmente depende de lo que quieras hacer al final.
+1 a itsmatt
En la pregunta original, evito personalmente los if anidados siempre que sea posible, de lo contrario terminaría con muchos códigos de flecha.
Sin embargo, hay excepciones a esta mini regla. Si va a haber un comportamiento diferente para cada uno de los resultados condicionales, los ifs anidados pueden ser una respuesta. Debe considerar cuidadosamente el impacto del anidamiento para no escribir código difícil de leer (y por lo tanto mantener).
Creo que depende de cómo quiera que fluya, si solo está ejecutando en verdadero, verdadero (o cualquier otra singularidad), entonces una declaración si es todo lo que necesita.
Depende de qué es exactamente lo que quiere lograr. Es una pregunta lógica en lugar de una consulta de programación. Si tiene una condición dependiente, es decir, si la primera es VERDADERO y luego prueba la segunda condición; si es segundo TRUE luego haga algo, si FALSE hace algo, en este caso necesita usar un if anidado. Pero necesita el estado de ambas condiciones para hacer algo, entonces puede ir con los operadores.
No iba a sonar, pero viendo que algunas respuestas aquí parecen ser "Me gusta que mi código se vea así" ... Siento que debería decir algo :)
"Mejor" significa que el código se ejecutará más rápido, o es más legible / extensible. Le conviene anidar su if en el caso de que posiblemente tenga múltiples cheques que tengan todos un requerimiento común.
Ejemplo:
if (myThingy != null)
{
if (myThingy.Text = "Hello") ...
if (myThingy.SomethingElse = 123) ...
}
EDITAR: También debe decirse que anidar sus IF requiere más ciclos de CPU (y por lo tanto es "más lento") que un solo IF. Además de eso, el orden de tus condiciones puede aumentar enormemente el rendimiento.
Exapmle nuevamente:
if (somethingQuick() && somethingThatTakesASecondToCalculate()) ...
es MUCHO más rápido (por supuesto) que
if (somethingThatTakesASecondToCalculate() && somethingQuick()) ...
Porque si falla la primera parte del IF, la segunda parte ni siquiera se ejecutará, ahorrándole tiempo.
Prefiero usar operadores condicional Y / O cuando sea necesario, en lugar de ifs anidados. Se ve menos complicado y tiene menos líneas de código.
if (thisIsTrue) {
if (thisIsTrueToo) doStuff();
}
es esencialmente lo mismo que:
if (thisIsTrue && thisIsTrueToo) doStuff();
si thisIsTrue es falso, la segunda condición no se evalúa. Funciona también para || para OR condicional
Realmente necesitas definir lo que quieres decir con "mejor".
Mi estilo es usar uno si y un Y si, como en su ejemplo, estoy probando lo mismo para dos valores diferentes.
Si las dos pruebas son conceptualmente diferentes, probablemente las anidaré
if (!user_option.work_offline) {
if (no_current_connection) {
start_connection()
}
}
Siento que es mejor evitar los if anidados.
A veces, incluso duplico pruebas simples para evitar un nivel de anidación.
Ejemplo (python):
# I prefer:
if a and b:
foo()
elif a and not b:
bar()
elif not a and b:
foobar()
elif not a and not b:
baz()
# Instead of:
if a:
if b:
foo()
else:
bar()
else:
if b:
foobar()
else:
baz()
A veces es más natural tener una cláusula else como última parte. En esos casos, normalmente afirmo las condiciones de la cláusula else. Ejemplo:
if a and b:
foo()
elif a and not b:
bar()
elif not a and b:
foobar()
elif not a and not b:
baz()
else:
assert not a and not b
baz()
En mi opinión, debes usar el estilo que tenga más sentido para lo que estás probando. Si los dos están estrechamente acoplados, puede probar ambos en la misma línea sin pérdida de claridad. Particularmente fácil cuando el programa permite construcciones "if x == (1 OR 2)".
Por otro lado, si las dos pruebas son inconexas, preferiría separarlas para hacer que la lógica sea más explícita.
nadie ha mencionado mantener ese código. ¿Cuál es más fácil de depurar?
si esto falla:
if (thisIsTrue && thisIsTrueToo)
doStuff();
usted sabe que una de estas dos declaraciones falló, pero no cuál.
si esto falla:
if (thisIsTrue) {
if (thisIsTrueToo)
doStuff();
}
su excepción le dice el número de línea. Digo que busque un mantenimiento fácil, ya que es probable que no esté en este código para siempre.