Hay que decir que en programación TODO tiene un costo, y no se menciona en este video. En este caso, estamos favoreciendo legibilidad, sí, pero el costo es que tenemos una variable más (LOKI_DISFRACES) que ocupa espacio en memoria, y a medida que esta variable aumenta, aumenta el espacio en memoria. Si bien esto en computadoras modernas podría ser insignificante, existe. Por ende "buenas prácticas" es muy relativo. Si vas a trabajar con javascript en microcontroladores que tienen poca memoria, esto no necesariamente es una buena práctica. TODO tiene un costo, y una habilidad importante como desarrollador es determinar cuál es el costo que nos conviene pagar.
el switch es pas pesado que el if.. si vamos a ocupar memoria en procesamiento entonces se ponen 3 if y es mas rapido... pasa lo mismo con PHP y sizeof y count.. una es alias de la otra y a nivel de ejecucion hay diferencias en procesamiento
Sos un gran docente, hace falta mas gente como vos para que mas personas le tomen amor a la programación. Felicidades y ojalá tuvieras una lista de reproducción de buenas practicas.
Quier decir que la verdad el video esta super bien explicado me encanta simplificar codigo y dejarlo de manera que se pueda leer y modificar con fasilidad, aca hice un ejemplo utilizando func, pasa que en c# creo que le tengo que rebuscar: static string adversario= "Iron-Man"; static string loki = string.Empty; public static void Sin_Switch_ni_If() { Dictionary LOKI_DISFRACES = new Dictionary(); LOKI_DISFRACES.Add("Iron-Man", "Magneto"); LOKI_DISFRACES.Add("Thor", "Odin"); LOKI_DISFRACES.Add("Hulk", "Thanos") Console.WriteLine("{0} vs Loki-{1}", adversario, LOKI_DISFRACes(LOKI_DISFRACES)); } public static Func LOKI_DISFRACes = (x) => { return (x.TryGetValue(adversario, out loki) == false) ? "Loki" : loki; };
Me salían tus vídeos en recomendados pero no los miraba, me dio por entrar a este video y la verdad uff, ha cambiado mi perspectiva, supongo que usaba el switch porque es lo que uno lee en la teoría que sirve para varias decisiones, uno se acostumbra tanto a la teoría que no le damos espacio a la creatividad de simplificar las cosas, muchas gracias amigo, me haz dado una perspectiva diferente.
Es genial ver este tipo de videos, me encanta aprender de mejores prácticas y esto se explica de manera sencilla y tremendamente didáctica, ojalá puedas seguir subiendo videos de este estilo! gracias midudev!
Me parece cool el approach, aunque me gustaría el contraste desde el punto de vista en el performance o memoria… se entiende que prácticamente todo lo que vemos son operaciones que son instantánea… pero no se me parece cool ver esa comparación nivel. Muchas buenas vibras.
Tengo algunos problemas en el uso de un objeto literal en lugar de un switch: - Es más lento (casi nada, pero aplicaciones de alto rendimiento se ven beneficiadas con switch) - Require una variable auxiliar para el default (require entender más código para mantenimiento) - Más verboso, por lo mismo del caso anterior. Para ejecutarlo hay que llamar al objeto, y a la variable auxiliar. - Memory allocation (el switch en un método se ejecuta dentro del stack, pero un objeto literal se almacena en el heap, y luego el GC tendrá que encargarse. Los lenguajes de alto nivel nos dejan trabajar sin pensar en ello, pero cuando tenemos mucha gente usando un sistema/servicio cada byte/ciclo afecta a la realción costo/ganancia) - Un objeto literal compacta todo el código naturalmente, switch lo estructura naturalmente. Esto depende del programador al final, pero realmente nunca vi menos legible el switch, aunque creo que es cuestión de gustos. Incluso switch indica cual es el punto de entrada, antes si quiera de separar el comportamiento. - Agrupar más de un caso requiere más código, cuando en switch los casos se pueden poner uno a continuación del otro. Al omitir el break, switch permite ejecutar varios casos a la vez. - No se pueden usar otras variables u objetos como caso para comparar (suele ser útil muchas veces) Usar un objeto literal tiene como ventaja: - Ser dinámico. No es una necesidad en la mayoría de los casos, pero en algunos poder añadir más casos al vuelo, puede ser necesario, y el switch no es útil ahí. - Aceptar proxys (no me acuerdo del nombre del diseño realmente). Pero es útil poder separar la lógica del negocio, de otros controles como puede ser el logging, o formateo de datos, etc. No creo que usar objetos sea un mal enfoque realmente. Creo que hay que saber en cada caso si realmente es necesario, y si la aplicación se beneficia a todos los niveles de la implementación.
Para el ejemplo puede mejorar la lectura del código, pero en rendimiento es peor, el tiempo de acceso a los elementos de un arreglo es mayor que una comparación que es lo que hace un switch, pese a lo que muchos piensen un switch es una estructura de control integrada en el propio lenguaje tanto como un if o un for.
Yo uso ambos. Hay casos que tiran más hacia un diccionario (como es el caso del vídeo), pero otros en los que no usar break para aglutinar varios cases y tener un único comportamiento, es más feo hacerlo con un diccionario. Otra cosa a favor del switch es el default que, si bien se puede simular como se hace en el vídeo, puede que haya casos en los que el valor "devuelto" en un case sea undefined y usando un diccionario no habría forma de saber si ha cumplido la condición (al menos tal cual se comprueba en el vídeo). La forma correcta para comprobar el caso por defecto con un diccionario sería mirando si la condición se encuentra entre las claves del objeto (Object.keys(LOKI_DISFRACES).includes(adversario)) y la elegancia que se gana con el mapa, se pierde en la comprobación del caso por defecto y tiene una sintaxis más fea y menos legible que con el switch. Otra cosa del switch es que "se ve" y sabes que ahí hay un un punto donde la lógica puede tomar N decisiones. El mapa "oculta" eso y a veces no es bueno si lo importante es buscar rápidamente en el código "el típico switch" donde se decide qué hacer. En casos simples y directos como los del vídeo usaría sin dudar el mapa, pero en otros creo que el switch deja más claro sus intenciones.
Debo admitir que he visto este video 3 veces , en un lapso de un mes. Siempre sin entender, pero después de haber resuelto unos problemas sobre objetos finalmente lo entendí. La calidad de la información no fue el problema, ya que está presentado de manera top. Mi falta de conocimiento fue el problema. Gracias desde 🇵🇦
Aun no se estrena pero ya le di Like! Pendiente de tus videos! Si todo sale bien entro a trabajar de Frontend con react asi que estos videos me vienen bien! Gracias
En serio que estos videos ayudan muchisimo a personas que recien inician y tambien a los que vienen programando... se aprende muy buenas practicas!!,. un saludo crack desde Perú.
Todo lo contrario viejo, los recién iniciados deben aprender a usar las sentencias básicas para después poder entrar a estructuras de datos y aprender a evaluar cuándo usar cada tipo.
Al principio ley el título del vídeo y me enojé! Porque siempre pensaba que reemplazar los ifs por switch era lo mejor, xD pero ya cuando te das cuenta que la idea no es usar ifs. Que locura y que increíble!!
El título no me hace sentido, el argumento para no usar SWITCH es que puedes usar un objeto ? el switch de hecho debería, a mi entender ser más usado ya que es más expresivo que un if, no me confundas, gracias por el aporte, en ese caso que tienes en el video es válido, al menos debiste aclararlo al final, ya que puedes confundir a los que inician, usar switch es bueno, moderadamente, como todo, gracias por compartir midudev.
GENIAL!! No uso mucho Java pero para hacer algo parecido me mataba haciendo condicionales anidadas o un bucle con dos arrays (uno de "entradas" y otro de resultados o "salidas") ya que solo podía buscar por posiciones numéricas y no por nombre de la posición como en este video. Gracias por brindarnos estos tips.
Me encanta este formato de videos, con temas/conceptos especificos y que van sumando a los conocimientos que se tienen, ademas que son puntuales y de no tan larga duración, excelente aporte, genio!
eliminaría mucho de código en redux!! ya lo hago para en otras cosas pero en reducers me lio . Y ya por 100k macho, en hora buena y mis mas sinceros respetos crack!! No solo saber, tener pedagogía para enseñar , transmitir y querer mas
Me puse a ver invinsible por recomendación de "alguien" y en cada capitulo esperando a ver si iban a programar en js vanilla o en react, y nada.... jejeje muy buena serie gracias... saludos desde Colombia!!
Me acabas de motivar categóricamente a continuar aprendiendo a programar. Estoy aprendiendo Python, acabo de ver diccionarios y justamente pensé en hacer lo que nos estás mostrando :) me siento feliz 😄
Maestro.. Buena... yo también so devoto del switch.. Pero todavía me cuesta entender la POO.. Soy de la guarda dinosauria.... hehehe (mi primer lenguaje fue basic en DOS) Pero sí, está buen esta manera de afrontar.. una... reduces código.. dos.. más legible. Puntazo....
Esta super la idea-- definitivamente me pasa que hago muchas condicionales asi y despues a parte de que es mucho codigo es dificil agregar o quitar algo-- Gracias-- definitivamente me sera util-- saludos--
midudev podrias hablar en un futuro video sobre children as function? como afectan el performance, si es recomendable segun en que casos. Esto lo pregunto por la primera vez que vi formik. Gracias!! {({ loading, saludar }) => ( {loading ? "Cargando.." : "Finalizo..!!"} )}
No termino de verlo como consejo general: switch y object son cosas diferentes que cumplen propósitos diferentes. Y usar un diccionario, en lugar de un switch no es necesariamente hacer código más legible... aunque puede que en este ejemplo seleccionado, tenga buen encaje (especialmente si también quiere reutilización del diccionario, como menciona en el vídeo)
Efectivamente es un ejemplo. La lectura es al revés. No digo que no uses nunca Switch. Digo que existe un uso que se le da a switch que es mejor usar un objeto. Y este caso es bastante repetido ya que casi todos los enums en JavaScript se convierten a switch/case.
👍 totalmente de acuerdo. Esto es una forma de evitar switch en un tipo de caso concreto. Que suele ser habitual pero no siempre es para dejar de usar switch.
@@midudev xd a mi el switch me parece una mrd, y con este video, creo q mas nunca lo usaré xD... algún ejemplo donde si toque estrictamente usar un switch ? a mi ni se me ocurre, soy NOOB cabe recalcar
Mi comentario tiende a ser un poco satírica pero hasta ahí llega eh, yo igualmente continuaré en este bello canal, pero pues si puedo ocasionar un chascarrillo lo voy hacer
buah, no sabía que es tan pero taaaaan extenso el javascript, de momento aún me cuesta en mi curso este lenguaje entre otros más pero es muy bueno si aprendo a usarlo pronto. Genial para cuando vaya de prácticas en empresa cuando encuentre para este Marzo.
Es curioso. Nunca había pensado en esta posibilidad . Pero usando objetos javascript sustituyes a switch. Hasta podría servir para php. Gracias por la sugerencia.
Justo ahora tenia un problema que no tenia idea de como solucionarlo, gracias a ti lo pude solucionar en 5 min. Gracias por compartir tu conocimiento! me salvaste de hacer 10 if else o switch jajajaj
Me parece increíble que esto fuera lo que hoy me ha dejado pensativo, no he podido pensarlo en el curro en condiciones y ahora llegas tú y literalmente me solucionas la vida, eres el Mesías, mim gracias Midu, un héroe siempre 🎉
Hoy hice mi segundo ejercicio y use switch jajaja igual estoy empezando llevo dos semanas. Necesita designar a cada día de la semana un número. Y Vi que con switch se podía . Aún no me se muchos comandos pero de a poco se aprende muchachos.
Hola! Oye estaría bien que explicarás cuales son los patrones que usas y así se aprende un poco más de teoría :D (Es este caso la factoría). PD: Parece mejor solución un "Optional chaining operator" que la ternaria, algo tal que así: "const loki = LOKI_DISFRACES[adversario]?.() || LOKI_DEFAULT_DISFRAZ". Buen video! :D
Gracias, complementando lo que escribiste podríamos escribir : "const loki = LOKI_DISFRACES[adversario]?.() || 'Loki' Nos ahorraríamos el definir LOKI_DEFAULT_DISFRAZ , ahorrar tiempo y espacio de memoria c:
Tengo la siguiente pregunta: Que tal el rendimiento de usar reflection para determinar el flujo de tu programa? En lo personal no me gustó por qué alterar el rendimiento solo por legibilidad no me convence. Pero igual siempre estoy dispuesto a aprender. Con una buena justificación podría cambiar de opinión!! Saludos
pero recordemos que tambien existe la recomendación de que un algoritmo lleva al principio la entrada de datos, luego el procesamiento y al final el resultado, por eso siempre al principio se declaran constantes para indicar que se analizo bien el contexto de lo que se pretende procesar y para que otros programadores cuando lean el algoritmo, al ver las constantes declaradas puedan tener una idea de que va el codigo, es una buena practica, y es muy recomendada, entonces a pesar de que para el hardware sea inconveniente, se hace es para el humano, luego existen los compiladores para optimizar el codigo programado a una forma optima para el hardware
recoerdemos que existen lenguajes con paradigma de programación imperativo y otro con paradigma a objetos y declarativo, el segundo caso los lenguajes permiten cierta abstracción de tener que declarar algo paso por paso y preciso como sucede en el imperativo, este es el caso de javascript, y por eso la popularidad que hace que las personas usen lenguajes de progrmación que permitan el paradigma declarativo, es como una personas que tenga 2 motos, una de 2 ruedas y otra de 4, y maneje la de 4 y se le critique porque esa gasta mas gasolina que la de 2 ruedas, pero la realidad es que es otra forma en la que se creó algo, allá cada quien si lo quiere usar o no. recordemos que por la comodidad de las 4 ruedas algunas personas buscaran eso, "la comodidad", lo mismo pasa aqui, se deja de lado la programacion imperativa (usar IF), por un metodo mas declarativo que hace todo mucho mas facil, en todo caso si quieren programar en paradigma imperativo pues busquen usar lenguaje C.
