Hola,
La pregunta es si cuando hacemos funciones recursivas, es una mala practica poner un return en cada caso del if, ejemplo:
IF condicion THEN
RETURN x
ELSE
RETURN y
end;
o hay que definirse una variable resultado y hacer
IF condicion THEN
resultado := x
ELSE
resultado := y
END
RETURN resultado
Desde ya gracias.
En respuesta a Matias Guzman Cubero Delgado
Re: RETURN en funciones recursivas
Yo tengo esta misma duda hace mucho, ví este post hace pila y lo dejé en marcadores a ver qué contestaban, estaría bueno que alguien tirara el pique..
Para mi no lo es.
De hecho en algunos prácticos se usa, si miras las soluciones, vas a ver return dentro de if. Miren algunos parciales.
Teóricamente sin embargo, un return es como un break, y el break está prohibido en este paradigma que estudiamos (programación estructurada....)
Yo les voy a ser sinceros... yo programaba de niño en basic y usaba siempre goto label y break. No entendía ni ahí el FOR y WHILE. Y cuando entré en la facultad, me costó muchísimo acostumbrarme al FOR y al WHILE para absolutamente todas las soluciones, esto en Programación 1. Igualmente logré salvar y me saqué de encima todas las "malas costumbres" de programación...
Yo no digo con esto que usen goto-label porque se van a quemar solos y hasta posiblemente pierdan el curso... Pero nunca está demás aprender recursos que no estan admitidos... y usarlos de vez en cuando (por ejemplo, en las planes de testing) ha de ser inofensivo en estos casos... Ademas... si por una de esas les toca agarrar un viejo programa de alguna empresa o banco local, y les toca pasarlo a .NET, pónganle C# que está de moda ahora, se pueden llegar a encontrar con una inmundicia hecha en COBOL de los años 70 u 80 plagada de goto label por todos lados... Ojo, no quiere decir que COBOL sea un mal lenguaje, pero simplemente en la época se programaba mal, y aveces se programaba muy mal...
Pero en definitiva, el RETURN es distinto a un break, porque no termina abruptamente un código, sino que cumple con el objetivo del bloque de código, que es retornar el valor en cuestión.
Quizás alguien del INCO les pueda explicar este detalle que no es menor pese a la sutileza o exquisités que tiene.
De hecho en algunos prácticos se usa, si miras las soluciones, vas a ver return dentro de if. Miren algunos parciales.
Teóricamente sin embargo, un return es como un break, y el break está prohibido en este paradigma que estudiamos (programación estructurada....)
Yo les voy a ser sinceros... yo programaba de niño en basic y usaba siempre goto label y break. No entendía ni ahí el FOR y WHILE. Y cuando entré en la facultad, me costó muchísimo acostumbrarme al FOR y al WHILE para absolutamente todas las soluciones, esto en Programación 1. Igualmente logré salvar y me saqué de encima todas las "malas costumbres" de programación...
Yo no digo con esto que usen goto-label porque se van a quemar solos y hasta posiblemente pierdan el curso... Pero nunca está demás aprender recursos que no estan admitidos... y usarlos de vez en cuando (por ejemplo, en las planes de testing) ha de ser inofensivo en estos casos... Ademas... si por una de esas les toca agarrar un viejo programa de alguna empresa o banco local, y les toca pasarlo a .NET, pónganle C# que está de moda ahora, se pueden llegar a encontrar con una inmundicia hecha en COBOL de los años 70 u 80 plagada de goto label por todos lados... Ojo, no quiere decir que COBOL sea un mal lenguaje, pero simplemente en la época se programaba mal, y aveces se programaba muy mal...
Pero en definitiva, el RETURN es distinto a un break, porque no termina abruptamente un código, sino que cumple con el objetivo del bloque de código, que es retornar el valor en cuestión.
Quizás alguien del INCO les pueda explicar este detalle que no es menor pese a la sutileza o exquisités que tiene.
Hola a todos:
En respuesta al mensaje original mi comentario es que simplemente es una cuestión de estilo de programación, siempre y cuando no pongan instrucciones debajo del RETURN dentro de alguna de las ramas del IF. Cualquier cosa que esté luego del RETURN no se ejecuta y ese es un error que cometen, sobre todo al principio.
A mi gusto queda mas claro tener un único RETURN al final y como dicen por allí mantener en una variable el resultado a devolver hasta ese momento.
Con respecto al mensaje que habla de los breaks y gotos también opino que es un tema de estilos de programación y en algunos casos puede ser útil usarlos.
En este curso desaconsejamos su uso (porque queremos que hagan las cosas de cierta manera), lo que no quiere decir que neguemos su existencia o digamos que NUNCA hay que usarlos. Como bien dicen por ahí hay que conocer las potencialidades y funcionalidades de los lenguajes y usarlas cuando corresponda. La gran crítica que usualmente se les hace a estas sentencias que "rompen" el flujo secuencial del programa es que hacen que el código sea difícil de comprender y de mantener, no tienen nada de malo en si mismas.
Pero en algunos casos pasa lo inverso! Usar GOTO por ejemplo puede hacer el manejo de errores en C mas prolijo que si no los uso (en C no hay manejo de excepciones). Miren por ejemplo esto
Espero haber sido clara
slds
Lorena
En respuesta al mensaje original mi comentario es que simplemente es una cuestión de estilo de programación, siempre y cuando no pongan instrucciones debajo del RETURN dentro de alguna de las ramas del IF. Cualquier cosa que esté luego del RETURN no se ejecuta y ese es un error que cometen, sobre todo al principio.
A mi gusto queda mas claro tener un único RETURN al final y como dicen por allí mantener en una variable el resultado a devolver hasta ese momento.
Con respecto al mensaje que habla de los breaks y gotos también opino que es un tema de estilos de programación y en algunos casos puede ser útil usarlos.
En este curso desaconsejamos su uso (porque queremos que hagan las cosas de cierta manera), lo que no quiere decir que neguemos su existencia o digamos que NUNCA hay que usarlos. Como bien dicen por ahí hay que conocer las potencialidades y funcionalidades de los lenguajes y usarlas cuando corresponda. La gran crítica que usualmente se les hace a estas sentencias que "rompen" el flujo secuencial del programa es que hacen que el código sea difícil de comprender y de mantener, no tienen nada de malo en si mismas.
Pero en algunos casos pasa lo inverso! Usar GOTO por ejemplo puede hacer el manejo de errores en C mas prolijo que si no los uso (en C no hay manejo de excepciones). Miren por ejemplo esto
Espero haber sido clara
slds
Lorena
Gracias, excelentes los ejemplos!