Diagrama de flujo, V(G) y alumno vs maestro

PinVa #1 Dic '13

Buenas, tengo una duda a ver si la solventarais las mentes pensantes.

Tengo el siguiente metodo super sencillo:

boolean a;

IF a THEN 
    RETURN x;
THEN 
    RETURN y;

Es simplemente un ejemplo de sentencia, donde hay dos return.

Los diagramas tienen un punto de inicio y un punto de final, entonces al hacer el diagrama del siguiente codigo, al tener dos return, ¿tendrian un mismo punto de salida?

Es que mi profesor dice que si tienes muchos return en un mismo metodo no es bueno y si son muchos al final no puedes calcular la complejidad ciclomatica ya que tiene diferentes puntos de salida, con lo cual es un codigo espagueti (antipatron) y no esta bien.

Y el caso que yo he visto muchos metodos de gente importante que utiliza mas de un return y no pasa nada.

¿Habria diferencia entre el codigo anterior con este?:

boolean a;

IF a THEN 
    salida = x;
THEN 
    salida = y;

RETURN salida;

Gracias!

Drhaegar #2 Dic '13 Inocente

Poder se puede, más de una vez he usado métodos con más de diez return y nunca he tenido ningún tipo de problema (era joven y me iba lo duro) pero no es lo correcto. Usar los minimos return hace que el código sea más legible y es lo estándar.

Echale un ojo.

http://stackoverflow.com/questions/36707/should-a-function-have-only-ONE-return-statement

ninjachu #3 Dic '13

#1 Yo también los he utilizado, y cuando existen muchos return repartidos por el código y la función es amplia, te acaba pasando que no sabes de un vistazo por donde va a salir.
Un método con Ifs anidados suele ser más claro.

Por otra parte, desde el punto de vista de ingeniería, los analizadores de código se mueven muy mal con returns intermedios.

Thanat0s #4 Dic '13 Cofrade

Yo hay en ciertos lenguajes (C++ y Java) que uso el mínimo número de return posibles, pero sin embargo en otros utilizo tantos como necesito (php).

Es cierto que con muchos calcular la complejidad es más difícil y no es recomendable.

mortadelegle #5 Dic '13

A mi siempre me han dicho, que use un solo return, mas que por otra cosa por la legibilidad del codigo, a lo hora de ver las entradas y salidas se ve claro que entra en el principio y sale por el final y no a medias.

La misma razon por la que siempre me han dicho de no usar break; salvo en switchs

1 respuesta

Fyn4r #6 Dic '13 Inocente

Yo prefiero varios returns a anidar sentencias IF. La lógica de la función se simplifica bastante normalmente.

P.D Si tu profesor es un taliban de los patrones de diseño te deseo paciencia xD

1 2 respuestas

Skiuv #7 Dic '13

Es muy sencillo: dentro de un año o unos meses (o unos días) cuando veas tu propio código no sabrás por donde cogerlo. Mucho menos otra gente. Los patrones no se inventaron porque alguien se aburría

1 respuesta

perez_chuck #8 Dic '13 Abe Sapien

#1 Son buenas prácticas de programación.
Con 2 return no habría problema para entenderlo, pero se recomienda usar siempre una variable auxiliar.

sasher #9 Dic '13

#7 Se inventaron porque un problema se repetía y se ideó una solución que parecía funcionar correctamente, lo cual no quiere decir que sean la panacea ni mucho menos.

De todas formas, el poner o no varios return en una función no es un patrón de diseño.

Scottie #10 Dic '13 :psyduck:

#5 Respecto al break, que solucion propones? no se, me cuesta ver algo que sea mas sencillo que eso :S

1 respuesta

mortadelegle #11 Dic '13

#10 Normalmente usar un while con una o varias condiciones dependientes de una variable booleana que cambia en un if, ilustro con un ejemplo:

spoiler

void readCode(tCode userCode, bool &canceled, bool &hint) {
	char c;
	int i = 0;
        tColor colorOut;

canceled = false;
hint = false;


cout << "Next move (? for help, ! for hint, 0 to exit): ";
cin.sync();

while ((!canceled) && (i < PEGS) && (!hint)) {
	cin >> c;
	c = toupper(c);
	if (c == '0') {
		canceled = true;
	}
	else if (c == '?') {
		help();
		cout << "Next move (? for help, ! for hint, 0 to exit): ";
	}
	else if (c == '!') {
		hint = true;
	}
	else if (c == 'R' || c == 'B' || c == 'G' || c == 'O' || c == 'P' || c == 'Y') {
		transformColorCharacter(colorOut, c, 0);
		userCode[i] = colorOut;
		++i;
	}
	else { //If user inputs wrong code the program will start getting again the array from the postion 0
		cout << "Valid color letters: R G B O P Y. Try again!" << endl;
		i = 0;
		cout << "Next move (? for help, 0 to exit): ";
		cin.sync();
	}
}
}

Tambien de paso es un ejemplo de un poco de nest de ifs y estructura if else if que la verdad al principio no me gustaba, pero joder no es taaaan fea

1

PinVa #12 Dic '13

#6 Si, el profesor es un taliban de los patrones de diseño jaja

Y a mi se me esta pegando porque la verdad que son muy útiles.

PD: Ayer fui al primer hackathon en España de Google Glass, algún día pondré un post sobre ello y lo que desarrollamos.

wineMan #13 Dic '13

Estoy con #6 en líneas generales.

Cuando sucede que tienes muchas condiciones en una función. Tienes 3 soluciones:

a) Anidar if uno detrás de otro. Personalmente lo odio. Es espaguetti total ahí con sangrados en escalera que parecen olas. Eso es desaconejable 100%.

b) Mejor que (a), es poner condiciones e ir haciendo returns. Es un código mucho más legible y mantenible.

c) El código limpio dice que cuando sucede esto, tienes que partir esa función en varias. Esto es lo que dice el manual de hacer las cosas bien. Una función no debería de sobrepasar las 20 líneas máximo.
Sobre todo hay que elegir esta opción si en los ifs se están evaluando condiciones que ejecutan código en "ámbitos" distintos.

Suelo optar por (c) o (b) dependiendo de varios factores. A veces es mejor no obsesionarse tanto con (c) y hacer (b) sirve y no molesta la conciencia. Pero bajo ningún concepto haría (a). Es lo menos legible y más difícil de mantener del mundo.

1 respuesta

eisenfaust #14 Dic '13

Los returns los carga el diablo.

PinVa #15 Dic '13

#13 a mi me decia mi profesor que lo que si era código espagueti eran muchos returns, porque
no sabes muy bien por donde te va a salir la función y que en vez de tener un punto de entrada y otro de salida tenia muchos de salida, y no se podía mantener.

Es verdad que cuando hay muchas sentencias, un if dentro de un bucle que cuando encuentre
algo en el bucle lo devuelva, es mas fácil que tener que hacer que se salga del bucle, y si hay mas sentencias que no pase por ellas.. etc...

Pero bueno si es mas correcto hacerlo sin muchos return, lo haré así, si es una función muy simple no pasa nada si pones 2 returns o así...

dagavi #16 Dic '13

Yo no se que limpieza o legibilidad os da no hacer un return xD

El típico caso que mas me encuentro es el de la función que comprueba parámetros y si falta alguno hace return (en vez de su lógica):

int* f(a, b) {
    if (a == NULL or b == NULL) return NULL;
    // hacer cosas
    return res;
}

La otra posibilidad

int* f(a, b) {
    res = NULL;
    if (a != NULL and b != NULL) {
        // hacer cosas
    }
    return res;
}

Yo me quedo con la primera, me gusta mucho más como queda el código. Y no añade un nivel de indentación que no aporta nada.

Otros casos mas hardcores son los que vas intentando generar un resultado y cuando lo consigues lo retornas. Si no haces un return al tenerlo es ir identando para nada el código, y añadiendo if/else.

int f() {
    // Intento generar un resultado
    if (res != NULL) return res;
    

// Lo intento de otra forma
if (res != NULL) return res;
...
}

Esto con que tengas 3 niveles ya canta mucho la identación.

Vamos, en resumen. Yo creo que es más por el propio código que estás escribiendo (no es lo mismo una función de 4 lineas que una de 100, y no en todas el return te lo cambia tanto) y del gusto del programador.

1 respuesta

PinVa #17 Dic '13

#16 yo creo que para cosas pequeñas si, pero si es un método mas grande que te hace tener mas de 3 y 4 returns entonces no es tan legible.

Esta claro que un método que hace un if else no pasa nada que pongas dos return, o dos if.

Soltrac #18 Dic '13 MV Wizard

Resharper te mete returns en el código para evitar el nesting. Es cómodo y más claro de leer.

Diagrama de flujo, V(G) y alumno vs maestro

Usuarios habituales

Tags