¡Qué buen video! Siempre me ha costado lidiar con los IF anidados, pero las guard clauses suenan como una solución genial. 🤔 ¿Alguien más ha probado esta técnica? Estoy empezando con сodigо herоe y me encanta aprender así. 😊
llevo haciendo esto por años y no sabía que tenía un nombre. solo que, exactamente como explicaste, es muy sencillo leer el algoritmo de esa forma. nunca pude explicar bien por que me gusta asi. ahora ya se w decirle a mis compas
@@neolymoreno3256 Si de hecho se recomienda mayormente las excepciones que los propios condicionales porque fuerzan el código a diferencia de los condicionales que se solo ejecutan cuando se cumple una condición es decir si hay cierta informacion que no puede ser procesada por el código salta la excepción ignorando el código restante. Es un gusto ayudar a la comunidad.
También podemos usar Switch Statement y optimizar aun más la ejecución de nuestro código, debido a que solo necesitamos una variable para movernos por el índice de opciones a comparar. No es lo mismo que un "if", pero no deja de ser una máquina de estados que según en que estado se encuentre la variable de control, pues ejecuta una acción u otra.
Vaya, a veces uno implementa cosas que según nosotros en ese momento es mera cuestión de comodidad, luego va y resulta que tienen un nombre técnico 🤣🤣🤣 Buen video.
y ahora con un debugger en vez de tener que entender el codigo, directamente me salto 3 instrucciones jne y soy usuario activo, pro y suscrito solo con cambiar un puntero. Gracias por la increible recomendacion de como no hacer software seguro!
Estuve pensando que podrías hacer algún video de 5 o 10 minutos de como escribir mejor código en dart. Por ejemplo usar más late en las variables, o más el operador ? en las varibles y objetos y no usar tantos if preguntando si es null la variables para luego hacer algo. Creo que eso tips nos servirían mucho a los que estamos todo el día con dart.
Estoy de acuerdo. Las cláusulas de guarda son una técnica útil para mejorar la legibilidad del código y evitar las condiciones anidadas. En lugar de tener una larga cadena de condiciones, se puede usar cláusulas de guarda para validar pre-condiciones y, en caso de no cumplirse, lanzar una excepción temprano. Esto permite una traza más clara de la lógica y hace que el código sea más fácil de entender y mantener. Además, también ayuda a reducir la posibilidad de errores y bugs en el código.
Lo tomaste de otro video en inglés, creo haberlo visto hace no mucho. De igual manera es bueno recordarlo y mas difundirlo en nuestro idioma. Saludos !
Muchas gracias, si cuando empecé a programar usaba esos if else, ahora ya no tanto y dependiendo de como hasta uso los switch case :) Muchas gracias por tu vídeo!!
Ademas de mas limpio, escuche que el procesador tiene que esperar para ver que es elegido, y haciendo operaciones constantes ayuda la velocidad del programa. O(1)
1:38 Corregime si es que estoy mal. El comando "showUserDashboard" en el primer método se ejecuta si las TRES CONDICIONES SON VALIDAS; mientras que en el segundo método se ejecuta siempre al finalizar las condiciones sin importar si son validas o negadas. Aunque el método esta bien, la ejecución de los códigos no son DOS FORMAS CON UN MISMO OBJETIVO sino que son dos códigos con diferentes funciones. En el segundo código deberíamos buscar una manera para que se siga cumpliendo la condición de mostrar "showUserDashboard" una vez las tres funciones son validas. PD: Repito, si me equivoco corregime. A primera vista es la manera en la que veo que funciona este código. Intentare codificarlo para ver si me equivoco en el proceso.
La verdad es que para una condición siempre pensamos en cumplir la condición y no cumplirla no es un pensamiento normal .. pero OJALA hubiera visto antes este video .. tengo muy poco aplicando esta técnica ..
Lo que hizo fue reescribir una función que hace una lógica AND como una lógica NOR a la que le niega las entradas, obteniendo la misma tabla de verdad al final. O sea se cumplen las mismas conexiones en ambos casos.
Buenas Diego! Tengo un tema del que podrías hacer un video corto que podría ayudar a muchos. Es el error: 'Consider canceling any active work during "dispose" or using the "mounted" getter to determine if the State is still active'. Estaría bueno poder entender bien como solventarlo y entender bien el concepto de "mounted" y cuando usarlo y cuando nop. En mi caso me aparecio en muchos momentos, incluso en navegaciones sin controllers o setStates.
Hay una construcción que está en casi todos los lenguajes y también puede servir en casos parecidos para dejar el código incluso más limpio: el switch case. En algunos lenguajes,como c, incluso se permiten expresiones en los case.
Es una técnica que uso desde hace más de 20 años (lenguajes bien viejos). No sabía que alguien se adjudicó autoría y le puso nombre. Bueno, también se puede usar en positivo en todo caso, sólo usa los conectores adecuados y ya.
Perdón por la corrección, pero no es un diseño correcto. La función que planteas está realizando dos cosas diferentes: chequear la condicion, y hacer algo. Lo correcto sería: void doSomething() { if (canDoSomething()) showUserDashboard(); }
No me parece que funcione en cada situación, les digo por qué. En el primer caso, si no se valida el primer if, nunca se va a llegar a la parte del codigo de adentro, en este caso, otros if. En el segundo caso, si no se valida el primer if, de igual manera se va a llegar al resto del código. Entonces suponiendo que el usuario no es activo, no está suscrito y no es ProUser: En el primer caso, las excepciones serían solamente 'Not a pro user' En el segundo caso, las excepciones serían 'User not active', 'User not subscribed' y por ultino 'Not a pro user' Corríjanme si estoy equivocado. Edit: no tiene sentido lo que dije, no conozco el lenguaje
No se trata que los IF anidados sean mala práctica, ocurre que el ejemplo que expones está intencionalmente confuso. Es muy común el uso de códigos anidados en los IF y sobre todo en los ciclos. Los programadores con tiempo y práctica van descubriendo como ir optimizando el código y depende caso a caso. En particular, si el programador tiende a complicar el uso de los IF, es que le falta compreder el uso correcto de los operadores lógicos y pulir el razonamiento en álgebra de Boole.
Aun recuerdo cuando una vez me dijeron que las Guard clause ya no se usaban que eran anticuadas 😆 cuando el código queda mas fácil y las guard clause apoyan mucho el fail fast principle
imagino que en este caso que ninguna condicional debe validar nada por el lado negativo? porque que pasa si debes efectuar alguna validacion por ejemplo si el usuario no esta activo?
Es buena práctica pero es bastante insuficiente. Para el ejemplo, que es bastante básico, alcanza, pero la realidad es que el problema con los if anindados se presenta cuando realmente, para cada nivel de anidación, hay sendos caminos que la ejecución podría seguir. En otras palabras, y tomando como ejemplo, el propio ejemplo del video, si para un usuario activo y registrado, pero no pago, tuvieras que invocar otro método diferente, esto es, dos if anidados pero con una salida diferente, entonces, ya no te sirve esta solución. Por lo general, yo para este tipo de cosas, utilizo "autómatas" o más bien, el principio de autómatas. Esto es, un arreglo de 2 dimensiones, donde defino reglas de transición de estados, esto es, para cada parte de los if anidados asigno un "estado", entonces, en función de las condiciones que se van cumpliendo, voy a ir "caminando" por los estados. Digamos que tengo un estado que es, usuario activo, otro que es usuario inactivo, otro que es usuario de paga, otro que es usuario gratuito, otro que es usuario registrado, y otro que es usuario sin registrar. Pues bien, yo defino un arreglo de dos dimensiones donde indicaré, a que estado tengo que ir, si la condición es una condición en particular, por ejemplo, mi estado inicial sería la posición 0 de la primera dimensión del arreglo, luego cada elemento de la segunda dimensión (o sea, cada columna de esa fila) me indicará el número de estado al que tengo que ir en cada caso (número de fila). Entonces, si se cumple la validación de que el usuario está registrado, tendré que pasar al estado de usuario registrado, eso es una posición del arreglo (de la primera dimensión, o sea, una fila), luego en esa fila, tendré la indicación de a donde ir en caso de que se cumplan las otras condiciones, o bien que no se cumpla ninguna. De ese modo, no importa la complejidad que tengan los if anidados, siempre tendré una solución simple y limpia. No tengo forma de ejemplificar mejor aquí pero sugiero que si alguien no comprendió lo que planteé, que busquen videos sobre autómatas de estado finito y matrices de estados.
Si sigues necesitando un else... Aunque a lo mejor tu código funciona de una forma diferente y si funciona bien. Teóricamente si necesitas ese else para encapsular bien ya que estas suponiendo que lanzar el exception impide lanzar el show pero 'y si no'... Mejor deja el else al final para que se ejecute específicamente cuando ya las condiciones si o si no se ejecutaron. Es también como la diferencia entre else if y if. Si pones dos if se ejecutan los dos si tener en cuenta el uno del otro. Pero si pones un if y luego un else if se ejecutará uno de los dos o ninguno.
Creo que llevas razón, perdona. Tengo que repasar este cuatri las excepciones en una asignatura que tengo. No sé porqué mi mente imagino que era algo propio de tu código y no algo nativo del lenguaje. Por eso creí esa suposición, gracias.
showUserDashboard no se estaría ejecutando siempre que llamamos a la funcion doSomething ?? Es decir.. si se cumple el primer if negado, showUserDashboard se ejecutaria igual ?
Esta bueno, pero solo es aplicable si tienes una sola funcion principal a la cual quieres llegar dentro de los ifs. Porque si tienes muchos ifs y cada combinacion de ifs y else requieren ejecutar una funcion distinta, no veo otra forma de seguir haciendo ifs anidados, o realizar if con varias condiciones en la misma linea
Corrigeme si estoy equivocado. No conozco el lenguaje. 1) La primera logica es mas larga pero mostrara un error a la vez; es decir si el usuario no cumple con las 3 condiciones a la vez. Solo se mostrara o subscrito, o activo o pago. 2) La segunda logica es mas corta pero mostrara los 3 mensajes de errores en caso de cumplirse todos a menos que instruccion throw haga un salto. Concluyo que depende de lo que queramos adaptamos el codigo. Saludos....
Diego to the moon! 🔥🔥🔥 Wish you the best with this video 🚀
thanks for the inspiration/idea and everything haha, :)
¡Qué buen video! Siempre me ha costado lidiar con los IF anidados, pero las guard clauses suenan como una solución genial. 🤔 ¿Alguien más ha probado esta técnica? Estoy empezando con сodigо herоe y me encanta aprender así. 😊
Excelente vídeo. Lo que sí, yo no diría "está mal" 0:08 Yo diría "ineficiente" pero mal no está.
no es ineficiente, es poco legible, son dos cosas diferentes
No es ineficiente, es ilegible. Y pudiéndolo hacer legible lo convierte en código mal hecho.
@@almogaverXIII Aun sigue siendo legible... simplemente no esta tan limpio pero ilegible no es.
Es ilegible para simples mortales
Esta mal dentro del contexto de la sintaxis
Tan sencillo que era y nunca lo vi de esta manera, muchas gracias :D
llevo haciendo esto por años y no sabía que tenía un nombre. solo que, exactamente como explicaste, es muy sencillo leer el algoritmo de esa forma. nunca pude explicar bien por que me gusta asi. ahora ya se w decirle a mis compas
Eso lo estudié en Estructura de Datos. Así el código corre más rápido cuando tiene muchos datos sobrecargándolo
chevere si tiene sentido porque las excepciones tienen la cualidad de frenar toda la ejecución del codigo cuando existe algún error buen método.🤗
Esto era lo que me hacía falta, jajaja gracias bro
Justo tenia esa duda, y yo pensando que estaba mal porque ejecutaría la función de todas formas
@@neolymoreno3256 Si de hecho se recomienda mayormente las excepciones que los propios condicionales porque fuerzan el código a diferencia de los condicionales que se solo ejecutan cuando se cumple una condición es decir si hay cierta informacion que no puede ser procesada por el código salta la excepción ignorando el código restante. Es un gusto ayudar a la comunidad.
Empecé a usar esto hace tiempo y definitivamente es un gran consejo para escribir código legible y escalable 👌🏻😎
También podemos usar Switch Statement y optimizar aun más la ejecución de nuestro código, debido a que solo necesitamos una variable para movernos por el índice de opciones a comparar. No es lo mismo que un "if", pero no deja de ser una máquina de estados que según en que estado se encuentre la variable de control, pues ejecuta una acción u otra.
Vaya, a veces uno implementa cosas que según nosotros en ese momento es mera cuestión de comodidad, luego va y resulta que tienen un nombre técnico 🤣🤣🤣
Buen video.
x2 llevo toda la vida haciendo las cosas así y ahora me entero de que existe un nombre para ello jaja
Una maravilla de explicación. Conciso y al pie, muchas gracias Diego! Bendiciones!
¡Gracias!
Bravo eres el primero que enseña Defensive Coding.
Pocos saben usarlo.
y ahora con un debugger en vez de tener que entender el codigo, directamente me salto 3 instrucciones jne y soy usuario activo, pro y suscrito solo con cambiar un puntero. Gracias por la increible recomendacion de como no hacer software seguro!
Incroyable.
@@mamneo2 :V
Muy buen tips! Muchas gracias! Ya mismo lo voy a implementar en mis proyectos!
Estuve pensando que podrías hacer algún video de 5 o 10 minutos de como escribir mejor código en dart. Por ejemplo usar más late en las variables, o más el operador ? en las varibles y objetos y no usar tantos if preguntando si es null la variables para luego hacer algo. Creo que eso tips nos servirían mucho a los que estamos todo el día con dart.
Corto, cómodo y fácil de entender esto si es un tutorial
Buen video! Simple y claro!
Si no quieres arrojar excepciones tambien podrías hacer return cuando quieras salirte del método.
El return rompería la ejecución de esa función?
Si
Estoy de acuerdo. Las cláusulas de guarda son una técnica útil para mejorar la legibilidad del código y evitar las condiciones anidadas. En lugar de tener una larga cadena de condiciones, se puede usar cláusulas de guarda para validar pre-condiciones y, en caso de no cumplirse, lanzar una excepción temprano. Esto permite una traza más clara de la lógica y hace que el código sea más fácil de entender y mantener. Además, también ayuda a reducir la posibilidad de errores y bugs en el código.
Excelente explicación, al grano y sin rodeos
Y dependiendo del lenguaje, puedes quitar los {} , como:
if(!isUserActive)
throw Exception(''User not active')
Lo tomaste de otro video en inglés, creo haberlo visto hace no mucho. De igual manera es bueno recordarlo y mas difundirlo en nuestro idioma. Saludos !
Eso mismo me percate 🧐
Sii, que observadores xd, Flutter Mapp me dió el permiso para basarme en su video.
Pero eso es como decir que le copiamos el syntax a Dennis Ritchie, del lenguaje C, son practicas conocidas por muchas razones.
lo querían quemar y les cerró la boca xd
@@ProyectoGD literal jaj
Muchas gracias, si cuando empecé a programar usaba esos if else, ahora ya no tanto y dependiendo de como hasta uso los switch case :)
Muchas gracias por tu vídeo!!
Excelente video, directo al punto sin tanto rollo
Ya lo sabia (se ve mas bonito pero es mas lento), gracias por compartir conocimiento.
Excelente Diegote , hoy me estaba enredando bastante en el laburo
Buenisimo, para poder sacarse la costumbre de hacer un laberinto de if jajaj
Esto no se me hubiese ocurrido, es muy ingeniosa tu solución. Nuevo sub con la campana activada.
Buenísimo!!! Recién estoy empezando así que me viene super el consejo. Muchas gracias :)
simple y bueno, no sabía su nombre... CRACK
Ademas de mas limpio, escuche que el procesador tiene que esperar para ver que es elegido, y haciendo operaciones constantes ayuda la velocidad del programa. O(1)
primer video tuyo que veo un genio total
Sencillo, potente... Perfecto.
Haddooouuukkkeeeennnn
es mi técnica de programación favorita, y eso que llevo casi 20 años escribiendo código fuente 😗
Muy buen video, se agradece que hagas un ciclo sobre buenas prácticas o estilos de programación.
Saludos.
1:38 Corregime si es que estoy mal. El comando "showUserDashboard" en el primer método se ejecuta si las TRES CONDICIONES SON VALIDAS; mientras que en el segundo método se ejecuta siempre al finalizar las condiciones sin importar si son validas o negadas. Aunque el método esta bien, la ejecución de los códigos no son DOS FORMAS CON UN MISMO OBJETIVO sino que son dos códigos con diferentes funciones. En el segundo código deberíamos buscar una manera para que se siga cumpliendo la condición de mostrar "showUserDashboard" una vez las tres funciones son validas.
PD: Repito, si me equivoco corregime. A primera vista es la manera en la que veo que funciona este código. Intentare codificarlo para ver si me equivoco en el proceso.
El throw Exception rompe el ciclo de ejecución
@@diegoveloper Como seria eso? Terminaria con el procedimiento directamente?
@@yukariakiyama3059 si, revisa sobre Excepciones, todos lenguajes de programación lo soportan
Gracias Diego, me ha gustado el vídeo, saludos :)
Me encanta como se ve el código así de ordenado y claro, y no un código hadouken
La verdad es que para una condición siempre pensamos en cumplir la condición y no cumplirla no es un pensamiento normal .. pero OJALA hubiera visto antes este video .. tengo muy poco aplicando esta técnica ..
Lo que hizo fue reescribir una función que hace una lógica AND como una lógica NOR a la que le niega las entradas, obteniendo la misma tabla de verdad al final. O sea se cumplen las mismas conexiones en ambos casos.
Buenas Diego! Tengo un tema del que podrías hacer un video corto que podría ayudar a muchos. Es el error: 'Consider canceling any active work during "dispose" or using the "mounted" getter to determine if the State is still active'. Estaría bueno poder entender bien como solventarlo y entender bien el concepto de "mounted" y cuando usarlo y cuando nop. En mi caso me aparecio en muchos momentos, incluso en navegaciones sin controllers o setStates.
Breve y super util. Tome su buen like hombre
¡Increíble!
mee encanto! Salute desde Arg!
Hay una construcción que está en casi todos los lenguajes y también puede servir en casos parecidos para dejar el código incluso más limpio: el switch case. En algunos lenguajes,como c, incluso se permiten expresiones en los case.
si, uno tiene a no usar switches pero suelen resolver situaciones que requieran usar muchas condiciones
prueba rust, con los match (switch) casi nunca debes usar los if, y es muchisimo mas seguro
Nunca lo había pensado. Muy buen dato.
Video clave, muy bueno!
Es una técnica que uso desde hace más de 20 años (lenguajes bien viejos). No sabía que alguien se adjudicó autoría y le puso nombre.
Bueno, también se puede usar en positivo en todo caso, sólo usa los conectores adecuados y ya.
lo aprendí a la mala cuando en el trabajo me pidieron pasarle el SONARLINTER al proyecto
Increíble cuando vi la miniatura del video pensé que se iba a utilizar algo diferente al if, pero solo fue el if digamos al revés.
Pienso que serviría sí tienes excepciones cosa que no siempre sucede. Allí me parece más limpia la anidación
Fantástico, lo hiciste tan sencillo
muy buena explicacion gracias
Joder, tras de hacer calistenia, también programa. Que grande Kass
Me encantó el tip, muchas gracias bro
Excelente video, muy bueno y bastante ilustrativo, gracias! 😁
Podríamos usar un else -if, en ciertas situaciones no?
Excelente diego gracias por compartir conocimiento, saludos
muy buenos consejos
Amigo haz un curso de java creeme que ayudarias mucho a la comunidad que pasa por profesores que solo "enseñan" pero sin vocación.
muy bueno el video! me suscribo, ojala saques mas videos como este
Perdón por la corrección, pero no es un diseño correcto.
La función que planteas está realizando dos cosas diferentes: chequear la condicion, y hacer algo.
Lo correcto sería:
void doSomething() {
if (canDoSomething()) showUserDashboard();
}
no entendí, compara el antes y después, ambas ejecutan lo mismo, ojo que el throw exception rompe el flujo de ejecución
No me parece que funcione en cada situación, les digo por qué.
En el primer caso, si no se valida el primer if, nunca se va a llegar a la parte del codigo de adentro, en este caso, otros if.
En el segundo caso, si no se valida el primer if, de igual manera se va a llegar al resto del código.
Entonces suponiendo que el usuario no es activo, no está suscrito y no es ProUser:
En el primer caso, las excepciones serían solamente 'Not a pro user'
En el segundo caso, las excepciones serían 'User not active', 'User not subscribed' y por ultino 'Not a pro user'
Corríjanme si estoy equivocado.
Edit: no tiene sentido lo que dije, no conozco el lenguaje
El throw Exception rompe la ejecución, ya no continúa
@@diegoveloper Jajaja lo sientooo, pensé que era otra cosa, no conozco ese lenguaje
@@andreslugo9947 excelente, tenia la misma duda, ya comprendi gracias a esta explicacion.
Gracias, héroe. Entendí con tu comentario jajajaja. Tonto no es el que pregunta , si no el que se queda con la duda 😄
justo iba a decir lo mismo
No sean dogmaticos. Las guard clauses son un patrón, y por lo tanto tiene pros y contras. No todo código puede ser mejorado al usarlas.
Se podría limpiar más sacando la llaves de los Ifs ya que es una sola línea. Excelente saludos!
pensé que ibas a tirar un switch o usar ternarios o algo así, pero me gustó el resultado, queda muy prolijo
Esto sirve para los casos.. Pero igual, buen aporte!
Muy bueno! Gracias, a aplicarlo!
Excelente, me suscribo 👍
No se trata que los IF anidados sean mala práctica, ocurre que el ejemplo que expones está intencionalmente confuso. Es muy común el uso de códigos anidados en los IF y sobre todo en los ciclos. Los programadores con tiempo y práctica van descubriendo como ir optimizando el código y depende caso a caso. En particular, si el programador tiende a complicar el uso de los IF, es que le falta compreder el uso correcto de los operadores lógicos y pulir el razonamiento en álgebra de Boole.
te dejo un super me gusta !gracias
Gracias bro, muy útil el consejo
Aun recuerdo cuando una vez me dijeron que las Guard clause ya no se usaban que eran anticuadas 😆 cuando el código queda mas fácil y las guard clause apoyan mucho el fail fast principle
Hay mucha gente que programa esas aguilitas incluso llegando a más de 10 niveles de indentación.
gracias Diego!
así lo aprendí de mi profesor de compiladores en la universidad :')
Ufff. Que recuerdos...no les pasó que por probar el codigo y hacerlo rapido...despues lo "arreglo"
imagino que en este caso que ninguna condicional debe validar nada por el lado negativo? porque que pasa si debes efectuar alguna validacion por ejemplo si el usuario no esta activo?
No es bueno dejarla por defecto al final en este caso, por que por alguna mala configuración de seguridad puede dar acceso.
Videazo!!!!!!
El: queda feo
Yo: akta escalerita
diego, te sigo por el thumbnail que te mandaste 🤣, Grande @diegoveloper!
Me gusto bastante muy bueno
Es buena práctica pero es bastante insuficiente. Para el ejemplo, que es bastante básico, alcanza, pero la realidad es que el problema con los if anindados se presenta cuando realmente, para cada nivel de anidación, hay sendos caminos que la ejecución podría seguir. En otras palabras, y tomando como ejemplo, el propio ejemplo del video, si para un usuario activo y registrado, pero no pago, tuvieras que invocar otro método diferente, esto es, dos if anidados pero con una salida diferente, entonces, ya no te sirve esta solución.
Por lo general, yo para este tipo de cosas, utilizo "autómatas" o más bien, el principio de autómatas. Esto es, un arreglo de 2 dimensiones, donde defino reglas de transición de estados, esto es, para cada parte de los if anidados asigno un "estado", entonces, en función de las condiciones que se van cumpliendo, voy a ir "caminando" por los estados.
Digamos que tengo un estado que es, usuario activo, otro que es usuario inactivo, otro que es usuario de paga, otro que es usuario gratuito, otro que es usuario registrado, y otro que es usuario sin registrar.
Pues bien, yo defino un arreglo de dos dimensiones donde indicaré, a que estado tengo que ir, si la condición es una condición en particular, por ejemplo, mi estado inicial sería la posición 0 de la primera dimensión del arreglo, luego cada elemento de la segunda dimensión (o sea, cada columna de esa fila) me indicará el número de estado al que tengo que ir en cada caso (número de fila). Entonces, si se cumple la validación de que el usuario está registrado, tendré que pasar al estado de usuario registrado, eso es una posición del arreglo (de la primera dimensión, o sea, una fila), luego en esa fila, tendré la indicación de a donde ir en caso de que se cumplan las otras condiciones, o bien que no se cumpla ninguna.
De ese modo, no importa la complejidad que tengan los if anidados, siempre tendré una solución simple y limpia.
No tengo forma de ejemplificar mejor aquí pero sugiero que si alguien no comprendió lo que planteé, que busquen videos sobre autómatas de estado finito y matrices de estados.
Que buena idea!!!!!!
Si sigues necesitando un else... Aunque a lo mejor tu código funciona de una forma diferente y si funciona bien. Teóricamente si necesitas ese else para encapsular bien ya que estas suponiendo que lanzar el exception impide lanzar el show pero 'y si no'... Mejor deja el else al final para que se ejecute específicamente cuando ya las condiciones si o si no se ejecutaron. Es también como la diferencia entre else if y if. Si pones dos if se ejecutan los dos si tener en cuenta el uno del otro. Pero si pones un if y luego un else if se ejecutará uno de los dos o ninguno.
En realidad no supongo nada, el throw Exception o el lanzar excepciones, siempre rompen el ciclo de ejecución
Creo que llevas razón, perdona. Tengo que repasar este cuatri las excepciones en una asignatura que tengo. No sé porqué mi mente imagino que era algo propio de tu código y no algo nativo del lenguaje. Por eso creí esa suposición, gracias.
@@jucls2002 no hay problema, el lanzar excepciones debería funcionar igual en los distintos lenguajes, solo que tiene distinta sintaxis seguramente
muy bien explicado, gracias :)
Me sentí bien Pendejo viendo lo fácil que es la solución xD, buen video
Sabían que en la programación orientada objeto, los condicionales sólo debe usarse un caso modulares (como en el ejemplo mostrado) y no procesamiento.
También un elif podría ser útil!
Buena. Agradecido y Suscrito.
Si usas calculo proposicional, podrás hacer todas esas condicionales en una sola, porque una condicional es una proposición lógica
El tema es realizar una determinada acción de acuerdo a una condición
Es un método más viejo que el hilo negro. No sabía que lo habían bautizado.
De todas maneras, es un excelente ejemplo para las nuevas generaciones.
Una consulta algun libro o algun recurso digital donde se puedan aprender este tipos de tecnicas, como tambien se hizo en el caso de SWTCH. Gracias.
Quizás el libro Clean Code, lo encuentras online también
showUserDashboard no se estaría ejecutando siempre que llamamos a la funcion doSomething ?? Es decir.. si se cumple el primer if negado, showUserDashboard se ejecutaria igual ?
El throw Exception rompe el ciclo de ejecución
Esta bueno, pero solo es aplicable si tienes una sola funcion principal a la cual quieres llegar dentro de los ifs. Porque si tienes muchos ifs y cada combinacion de ifs y else requieren ejecutar una funcion distinta, no veo otra forma de seguir haciendo ifs anidados, o realizar if con varias condiciones en la misma linea
yo lo usaba inconscientemente xd
Agradezco al Algoritmo de youtube por recomendarmelo
Una idea magnífica: sirve incluso en Python (se que muchos pensaron que usarías un SWITCH en lugar de IF).
Corrigeme si estoy equivocado. No conozco el lenguaje. 1) La primera logica es mas larga pero mostrara un error a la vez; es decir si el usuario no cumple con las 3 condiciones a la vez. Solo se mostrara o subscrito, o activo o pago. 2) La segunda logica es mas corta pero mostrara los 3 mensajes de errores en caso de cumplirse todos a menos que instruccion throw haga un salto. Concluyo que depende de lo que queramos adaptamos el codigo. Saludos....
hola, el throw Exception rompe el ciclo de ejecución, ya no evaluará las demás condiciones
Cool! Muchas gracias,
Lo uso pero no sabia como se llamaba, lo aprendi de Fazt Code
Gracias crack!!! 😀