[GUÍA] Estrategias de programación

#2

#1Kr4n3oK:

¿Es correcto romper el condicional de esa manera?

Mi respuesta a esta pregunta es Sí, por poder puedes.

#1Kr4n3oK:

¿es mejor opción usar el condicional entero con su if..else..?, ¿debería romperse la ejecución usando return?

La primera Sí y la segunda No

Ambas respuestas las llevo al razonamiento del que return te va a sacar de la función, en el caso que planteas sería correcto porque no hay nada más que hacer en dicha función, pero lo veo una mala práctica ya que mucho casos tu función continuará dependiendo de los resultados de ese if... else...

A parte es más legible con la estructura completa del if... else... es más fácil y ameno de leer se entiende mejor, y es algo que se agradece cuando no es tu código.

PD: Me mola mucho la propuesta, espero que avance y va a favs

Jesus, cuanta cosa mal en tan pocas lineas.

#2
El codigo esta bien pero, a mi modo de ver, si me dieran el proyecto, y tuviera que estudiarmelo para seguir con el, si por algun casual, se me pasara ese return, o lo que sea, pensaria que los metodos de abajo los llama independientemente de si el if se cumple o no.

Prefiero un if else de toda la vida.

#2 Depende mucho de lo que haga la funcion, y sobre todo su extension. Yo soy fan de los early returns en bastantes casos, sobre todo para comprobar funciones iniciales y abortar ejecucion si no se dan unos casos minimos.

En el caso que has puesto pondria un if/else, porque solo estas teniendo un retorno de la funcion; no sale muy a cuenta tenerlo para ese solo caso.

Sin embargo, un retorno temprano es muy util en casos como este:

private openToEditForm (row: Object, editMode: EditMode) {
    if (row == null) {
        throw new NullReferenceException("row cannot be null");
    }
        

if (editMode == EditMode.Rename) {
    throw new InvalidValueException("Entry renaming is disabled");
}

this.createForm.setValue(row);
this.createForm['toedit'] = true;
this.createForm['visible'] = true;
}

Y por supuesto, otras cosas que son cuestionables en el codigo:

• No llames a la UI directamente dependiendo de tu arquitectura, separalo en capas para evitar interdependencias.
• Usa setters/getters en vez de poner las propiedades a saco.
• Usa variables tipadas en vez de magic strings para acceder a las propiedades.

#12 gracias por la parte que me toca, cuando quieras comparamos historico de aportaciones a este foro machote.

#13 Estoy seguro de que eres un tío de puta madre y que en persona eres mas de ayudar que de criticar, pero eso no quita que yo aquí siempre te haya visto primero lanzando la piedra, y ya luego si eso ayudando (como has hecho en tu comentario, que me ha molado mucho). Si #1 abre un hilo y tu respuesta es la que es de primeras, generas una sensación negativa.

En cuanto a lo de compararnos, no dudo que tu hayas aportado más que yo. En lo que a mi respecta me gusta mantenerme más low profile y soy más de ayudar por privado soltando parrafadas cuando vienen a buscarme, aunque en este caso quería dar mi opinión.

#16 "interrumpir el flujo del programa"? Aqui no estas interrumpiendo nada, tiene (casi) el mismo efecto un if/else que un return. Me parece que te has liado tu solo.

#15 es mas facil trolear que ayudar, menos esfuerzo.

#20 tipico comentario de profesor de carrera que no ha programado fuera de docencia en su vida. Que equivocados estaban cuando me ense;aron asi.

https://softwareengineering.stackexchange.com/a/118793

Pues yo debido a como esta el codigo en el trabajo hay veces que es infumable con los if-else kilometricos para comprobar ciertos parametros (o meterlos todos es una condicion if ....)

Prefiero mil veces como lo hace r2d2rigo (que al final es lo que hago yo). Porque compruebas que todos los parametros estan bien y cumplen el formato, y si todo es correcto pasas a procesar los datos. Si no, envías a una pantalla de error. De forma que sabes que las primeras partes del codigo son comprobaciones, las segundas son simplemente ejecuciones.

Antes lo hacia con returns pero con el tiempo te das cuenta que es mejor crearte una excepción y propagarla hacia arriba. Ya sera la funcion caller, o el controller quien se encargue de capturar y mostrar un mensaje especifico para el error propagado.

Es igual que cuando haces un for hasta encontrar una condicion: Ejemplo estas buscando en un array de String que una posicion sea igual a un texto (por ejemplo, los roles que dispone una persona).

String[] roles = new String[]{"GUEST", "USER", "PROVIDER", "ADMIN", "OFFICER"};
String texto = "ADMIN";
boolean found = false;
for ( int i = 0; i<roles.length;i++) {
 if ( texto.equals( roles[i] ) ) {
  found = true;
  break;
 }

}

if ( !found ) {
 throw new UserHasNoPrivilegesException("No se disponen de los permisos requeridos para ejecutar esta accion");
}

// Como tiene permisos, ejecutamos las instrucciones correspondientes.
// bla bla bla bla

#26 Al final todo es el fantasme de los GOTO.