Hola, buen curso, me esta gustando, pero tengo una duda, no se supone que es una mala practica el poner muchos “return” en una función? E...

O sea sí, pero no. Siempre que hablemos de buenas o malas prácticas debemos entender el contexto. . La explicación de este "dicho" es que los "returns anticipados" dificultan la legibilidad de nuestro código. Esto porque uno normalmente espera que las funciones retornen algo y por sentido común siempre retornan ese algo al final:

• https://stackoverflow.com/questions/36707/should-a-function-have-only-one-return-statement
• https://www.anthonysteele.co.uk/TheSingleReturnLaw.html

. Pero también podríamos hablar de patrones como el Error First (e.j. terminar la ejecución de una función si nos encontramos un error antes de desarrollar el resto de la lógica de X funcionalidad):

• https://www.geeksforgeeks.org/error-first-callback-in-node-js/
• https://stackoverflow.com/questions/40511513/why-does-node-prefer-error-first-callback

. ¿Cómo así? ¿Entonces son dos "buenas prácticas" contradiciéndose la una con la otra?

Ehjmmm... sí... más o menos. Mi forma de no totearme el cerebro con esto es tratando de entender el por qué detrás de cada práctica en vez de seguirlas al pie de la letra. . El objetivo de los "no returns anticipados" es que las funciones sean fáciles de leer y que sea fácil identificar dónde retornamos información. Y el objetivo del error first es que sea fácil identificar dónde "catcheamos" errores antes de escribir el resto de lógica de la app. . Teniendo todo esto en cuenta, mi veredicto final (super personal, cada quien puede tener opiniones o conclusiones completamente diferentes) es que lo importante es escribir funciones con buena legibilidad. Si es difícil identificar dónde va nuestro return, podríamos mejorar eso. Si es difícil identificar dónde "falla" nuestro código y eso se puede corregir con un return anticipado, se lo voy a poner, vale la pena, no le tengo miedo al éxito hehe. :green_heart:

Gracias por la respuesta, me queda claro :)