Emilio muchísimas gracias por este excelente contenido, la verdad hasta ahora estoy aprendiendo Python pero si he visto ese tipo de código difícil de leer y mantener en muchos trabajos y en muchos lenguajes, que nos enseñes a ver un código mas limpio con esta sencillez, con paciencia y cariño es espectacular. MUCHAS MUCHAS GRACIAS!!!
Gracias por compartir este tipo de visión algorítmica, que te permite ver las cosas de una forma diferente y aporta a seguir trabajando de una forma más elegante y pro
El vídeo es bastante didáctico.Yo os propongo como ejercicio, extender el ejemplo para conseguir que cada función tenga un único punto de entrada y uno de salida (solo un return por función). Y ya de paso, no dejar nunca un IF sin su ELSE. Aunque en el else no haya que hacer nada, se pone con un comentario para recordarlo... bienvenidos al desarrollo de software crítico.
Hola @ProductCrafter, muy buen video, siempre utilizo los early returns. Quería hacerte una recomendación para próximos videos: suelo verlos desde el móvil o en una segunda pantalla del PC, y noté que el código que mostraste se veía algo pequeño. Creo que sería ideal que le hicieras zoom para que sea más fácil de leer. ¡Gracias y sigue así!
Mensaje sutil pero importante: antes de refactorizar una función, asegúrate de tener pruebas que verifiquen su funcionamiento con todos los cambios propuestos. Gracias por tanto.
La explicación es buenísima, pero sí que he echado de menos comentar el antipatrón Martillo de Oro. Sobrerefactorizar también provoca flujos de código complicados de seguir y mantener. La virtud está en encontrar el equilibrio entre el uso de Early Return y el uso tradicional del else. En este ejemplo, podrías haber calculado el multiplicador base (usando 1 para el caso normal), añadir un parámetro a la función que calcula el precio final, y te ahorras crear una función con exactamente el mismo proceso que la inmediatamente anterior.
Totalmente de acuerdo! No hay una forma única de hacer las cosas y saber aplicar cada idea en cada momento es lo que requiere habilidad. Gracias por comentar!
@@ProductCrafter No es ser extremo, es que el mismísimo assembler tiene ELSE. Es imposible que un programa funcione sin comparaciones, saltos (o no salto) y operaciones matemáticas... es todo la base de lo que una CPU hace.
Soy desarrollador de software desde hace 35 años. Estoy de acuerdo en que no hay que abusar de estructuras poco claras, pero también te digo que no me gustan los absolutismos. Es decir, según el contexto, un else, puede ser aceptable e incluso la forma más óptima. Además también el else es una forma de quitar computo al sistema, es decir, cada vez que haces un if, obligas al código a computar, y a veces hay que buscar el equilibro entre legibilidad y optimización. Saludos
Excelente video. Aún los métodos para calcular según es_holiday podrían simplificarse en uno solo, ya que se repite el código y sólo cambia la condicional cuando es holiday y cuando no
El problema aquí no son los elses, sino los ifs anidados. Creo que aquí no hay contriversia, es casi un consenso que los early returns son preferibles a los ifs anidados
A mi una vez me dijeron que es preferible un código más explícito que implícito aunque sea más largo el código, que opinas de eso respecto a tener en cada if un else(? Aunque lo de usar if not para retornar antes el error me pareció bastante ingenioso, lo mismo con crear un método, se redujo mucho las identaciones, gracias por los consejos!
Creo que ambos metodos se pueden mergear a un solo calculate_price() y para manejar los holidays podias definir dos diccionarios, uno para holidays y otro para dias normales. Igualmente buen video!!!
Sisi, se puede hacer así, aunque yo muchas veces si veo un if el cuerpo me pide que sean dos métodos, pero como dices puede quedar una buena solución como comentas! Gracias por compartir tus ideas! 🙌
Se puede refactorizar mucho mas, usando un equivalente a Swich, para eliminar los if tambien, un detallito q vi x ahi en test, es q paso d 0.06 seg a 0.1 y luego otra vez bajo
early return, yo hacia eso y le llamaba condicional inversa xdd, en lugar de confirmar si la condición es cierta, verifico si la condición es falsa y luego return
Memoria y coste temporal es el mismo, haces el mismo número de operaciones y los condicionales almacenan la misma memoria que guardarlo previamente en una variable (un booleano). Solo tiene una asignación extra que no debería tener coste notable. Gracias por comentar!
En el video veo que usas Python 3.11, pero MacOS (tanto Sonoma como Sequoia) proveen Python 3.9. ¿Cuál método recomendarías para usar una versión más nueva de Python en MacOS?
Pyenv te permite instalar varias versiones de Python en tu ordenador. Además, en una carpeta (p.e. un nuevo proyecto) puedes definir la versión específica de Python a usar. Pyenv creará un archivo de configuración en esa carpeta y al ejecutar "python -V" desde el terminal en dicha carpeta tendrás la versión que indicaste.
![Seungmin "그렇게, 천천히, 우리(As we are)" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/kAzmhLHePqU/mqdefault.jpg)
Emilio muchísimas gracias por este excelente contenido, la verdad hasta ahora estoy aprendiendo Python pero si he visto ese tipo de código difícil de leer y mantener en muchos trabajos y en muchos lenguajes, que nos enseñes a ver un código mas limpio con esta sencillez, con paciencia y cariño es espectacular. MUCHAS MUCHAS GRACIAS!!!
Me alegro que te haya aportado! Gracias a ti por comentar!
Excelente video, deberia ser obligatorio verlo para todos los que vayan incursionando en el desarrollo
Gracias!! 🙌
Gracias por compartir este tipo de visión algorítmica, que te permite ver las cosas de una forma diferente y aporta a seguir trabajando de una forma más elegante y pro
Gracias a ti por comentar!
Guau, como se agradece tocar un código en el que no necesitas hacerte un plano para entender que es lo que hace, estás técnicas son mano de santo.
Más de un plano de esos que comentas me he tenido que hacer jaja
Me han gustado los comentarios sobre el precio base del ticket. Like
Una excelente explicación, sencilla, clara y concisa, gracia por el aporte.
Gracias a ti por comentar! 🙌
El vídeo es bastante didáctico.Yo os propongo como ejercicio, extender el ejemplo para conseguir que cada función tenga un único punto de entrada y uno de salida (solo un return por función). Y ya de paso, no dejar nunca un IF sin su ELSE. Aunque en el else no haya que hacer nada, se pone con un comentario para recordarlo... bienvenidos al desarrollo de software crítico.
🤔
Hola @ProductCrafter, muy buen video, siempre utilizo los early returns.
Quería hacerte una recomendación para próximos videos: suelo verlos desde el móvil o en una segunda pantalla del PC, y noté que el código que mostraste se veía algo pequeño. Creo que sería ideal que le hicieras zoom para que sea más fácil de leer. ¡Gracias y sigue así!
Sin problema! La próxima vez que grabe le doy algo más de zoom (video para dentro de un par de semanas que ya tengo alguno grabado)
descubrir las claúsulas de guarda me salvaron cuando estaba empezando jajaja gran vídeo
Es un antes y un después en la claridad del código 😅
Mensaje sutil pero importante: antes de refactorizar una función, asegúrate de tener pruebas que verifiquen su funcionamiento con todos los cambios propuestos.
Gracias por tanto.
Tests siempre!! Gracias a ti por comentar!
Muy buen video, la verdad es que eliminar los else cambia mucho la forma de ver el código, intentaré aplicarlo.
Gracias
Gracias a ti por comentar! Me alegra que te haya servido
La explicación es buenísima, pero sí que he echado de menos comentar el antipatrón Martillo de Oro. Sobrerefactorizar también provoca flujos de código complicados de seguir y mantener. La virtud está en encontrar el equilibrio entre el uso de Early Return y el uso tradicional del else. En este ejemplo, podrías haber calculado el multiplicador base (usando 1 para el caso normal), añadir un parámetro a la función que calcula el precio final, y te ahorras crear una función con exactamente el mismo proceso que la inmediatamente anterior.
Totalmente de acuerdo! No hay una forma única de hacer las cosas y saber aplicar cada idea en cada momento es lo que requiere habilidad. Gracias por comentar!
Muy buen video bro!! Saludos
Muy buenos vídeos, sirven un montón, sobre todo a personas como yo que estamos empezando, sigue así tio!
Gracias!! Me alegro de que te haya servido, seguiré en esta linea!
Hola bro, sigue asi con estos videos de refactorizacion de codigo, siento que he mejorado un poco mas porgramando
Me alegro de que te sirvan!! 🙌
Buen aporte. Igual, al que me dice que "los else están prohibidos" lo saco de mi equipo!
Yo nunca soy de extremos, nunca digas nunca a algo! Cada problema tiene su herramienta, solo hay que saber utilizarlas
@@ProductCrafter No es ser extremo, es que el mismísimo assembler tiene ELSE. Es imposible que un programa funcione sin comparaciones, saltos (o no salto) y operaciones matemáticas... es todo la base de lo que una CPU hace.
Que increíble video y muy bien explicado
Soy desarrollador de software desde hace 35 años. Estoy de acuerdo en que no hay que abusar de estructuras poco claras, pero también te digo que no me gustan los absolutismos. Es decir, según el contexto, un else, puede ser aceptable e incluso la forma más óptima. Además también el else es una forma de quitar computo al sistema, es decir, cada vez que haces un if, obligas al código a computar, y a veces hay que buscar el equilibro entre legibilidad y optimización. Saludos
Un curso de programación tuyo si valdría la pena, pagaría por el.
Me alaga!! Pero no tengo tiempo para hacer cursos 😂 Voy a tope jaja
Excelente vídeo
Excelente video. Aún los métodos para calcular según es_holiday podrían simplificarse en uno solo, ya que se repite el código y sólo cambia la condicional cuando es holiday y cuando no
Desde hoy no utilizaré más Elses! Gran explicación!
Gracias!! 🙌
Qué útil!
El problema aquí no son los elses, sino los ifs anidados. Creo que aquí no hay contriversia, es casi un consenso que los early returns son preferibles a los ifs anidados
Y vosotros, ¿Os gustan los elses o los evitáis? 🤔
Ahora que lo pienso desde que intento ser más redundante y directo en mi código no he usado else en muchooooo tiempo
depende, porque hay veces que lo utilizas para que no corra todo el código después de que un if funcione
Odio los ifs anidados
Los if anidados es para cuando c esta aprendiendo a usarlos, lo ideal es usar un equivalente a swich con diccionarios
Qué tal calcular el factor y una única operación de cálculo?
También se puede hacer sí! Con que quede claro para el siguiente desarrollador es lo importante
A mi una vez me dijeron que es preferible un código más explícito que implícito aunque sea más largo el código, que opinas de eso respecto a tener en cada if un else(? Aunque lo de usar if not para retornar antes el error me pareció bastante ingenioso, lo mismo con crear un método, se redujo mucho las identaciones, gracias por los consejos!
Creo que ambos metodos se pueden mergear a un solo calculate_price() y para manejar los holidays podias definir dos diccionarios, uno para holidays y otro para dias normales. Igualmente buen video!!!
Sisi, se puede hacer así, aunque yo muchas veces si veo un if el cuerpo me pide que sean dos métodos, pero como dices puede quedar una buena solución como comentas! Gracias por compartir tus ideas! 🙌
Me encanta este contenido!
Gracias!! 🙌
Se puede refactorizar mucho mas, usando un equivalente a Swich, para eliminar los if tambien, un detallito q vi x ahi en test, es q paso d 0.06 seg a 0.1 y luego otra vez bajo
El fácil invertir el codigo, solo usar if, luego volar los if de un escopetazo y usar operadores y piumba código refactorizado
Tan finos los vídeos Bro
Gracias bro 🙌
Viva el codigo claro.
No soy hater de los else's pero soy fan de las clausulas de guarda (o sea, de los early returns)
Yo soy muy fan de lenguajes como Swift que directamente tienen un "guard" implemetando como una función más del lenguaje 🔝. Gracias por comentar!
early return, yo hacia eso y le llamaba condicional inversa xdd, en lugar de confirmar si la condición es cierta, verifico si la condición es falsa y luego return
Tiene muchos nombres jaja, también se le llama guard clause por si lo ves por ahí. Gracias por comentar!
¿Cual es el coste de memoria a largo plazo con este método? ¿cual es más eficiente algoritmicamente hablando? . Buen video🎉.
Memoria y coste temporal es el mismo, haces el mismo número de operaciones y los condicionales almacenan la misma memoria que guardarlo previamente en una variable (un booleano). Solo tiene una asignación extra que no debería tener coste notable. Gracias por comentar!
@ProductCrafter Gracias por responder
En el video veo que usas Python 3.11, pero MacOS (tanto Sonoma como Sequoia) proveen Python 3.9.
¿Cuál método recomendarías para usar una versión más nueva de Python en MacOS?
Pyenv te permite instalar varias versiones de Python en tu ordenador. Además, en una carpeta (p.e. un nuevo proyecto) puedes definir la versión específica de Python a usar. Pyenv creará un archivo de configuración en esa carpeta y al ejecutar "python -V" desde el terminal en dicha carpeta tendrás la versión que indicaste.
El mejor video de programación de todo el internet!
Alaaa 😂 Gracias!!
Evitemos los else.
Abajo los else xd