Comunidad Gambas-es

Hola!.

No es nada nuevo para los que ya llevamos un tiempo.
Es una manera de diseñar nuestra aplicación. A veces ocurre con las variables, con nuestros
procedimientos o funciones.

A la hora de nombrar una variable, debemos nombrarla de alguna forma que al
ver su nombre nos diga sin muchos rodeos, que almacena.

A la hora de crear los procedimientos y o funciones, ocurre igual.
Bien, los nombres deberían de alguna forma decir que hace de la manera mas breve.
A veces creamos unos nombres muy largos.

Bien, a la hora de la construcción de la aplicación.Deberíamos crear un esqueleto
de la misma. Ya no me refiero a los saltos, pasos de un lugar a otro. No,
me refiero a esquematizar cada nombre de función y lo que hace.

Si decimos:

Lo que hace el código:
Muestra el tablero del juego en la pantalla en base a la estructura de datos pasada,
incluyendo las coordenadas de arriba, abajo y los lados izquierdo y derecho.

La función que lo hará:
DibujarTablero

Es un ejemplo, claro. Cuando nuestra aplicación crece, debemos controlar
cada acción y nombrar claramente las funciones. Y tener por seguro que serán
muchas!.

¿ Donde deberíamos situar este esqueleto de funciones o procedimientos ?.
Pues no seria mala idea de hacer un dibujo con bloques, con una aplicación o
con lápiz y añadirlo de alguna forma, ya sea en el árbol de nuestra aplicación
o tenerlo cerca...(se pierde, fijo)..

Y ahora, añadir vuestros comentarios y sugerencias para mejorar nuestra manera de hacer las aplicaciones.

No olvidar los comentarios, eso siempre deben de tener nuestras aplicaciones.

Saludos

Pues yo me he acostumbrado a crear un "diagrama de flujo" básico del programa. Luego las funciones, procedimientos y cada uno de los controles con un nombre que diga a golpe de vista lo que hacen.
Un gran programador me dijo que lo primero es tratar de describir el programa como si lo fuera a realizar otro, para ver que tan claro lo tenemos nosotros mismos.Y plantearlo lo más abstracto posible, sin mencionar controles ni nada.
Si lleva base de datos, la siguiente fase es diseñarla . Despúes, distribuyo los controles en el o los formularios y por último, paso a codificar y probar. A la hora de probar, me pongo en el lugar del usuario y trato de hacer todo lo que no debería para probar la solidez del programa y los posibles bugs y/o errores tontos (los más comunes y los más difíciles de encontrar).
A la hora de codificar es cuando más googleo, busco en el foro y en la web de gambas, cuando surgen dudas o pruebo cosas nuevas.
Y por último, a compartirlo con la comunidad.
Saludos.

Hola Dani.

Cuando las aplicaciones son grandes, resulta un poco mas difícil de realizar un diagrama de flujo con todos sus símbolos.
Y si es pseudocódigo, peor.

Cuando las aplicaciones son mas o menos cortas, resulta mas sencillo. Si en el diagrama de flujo usamos una serie de símbolos
que representan entradas, salidas, operaciones, serian muchos símbolos. Entonces te refieres mejor a crear un bloque cuadrado por funciones
o procedimientos de lo que hace la aplicación. ¿ No ?.

Ejemplo del libro de Python que estoy intentando acabar.A modo simple.



Cuando la aplicación es mas grande, se complica, ejemplo de TicTacToe.



Cuidado con las flechas. Cuerpo a tierra!.


Saludos

Shell, creo que nunca he hecho una aplicación verdaderamente grande, quizá debería llamarlo mejor "diagrama de bloques". Te muestro un par de ejemplos míos para que quede más claro.


Claro que siendo grandes, los podrás dividir en partes, como en las siguientes imágenes:



Y sí, supongo que a medida que los desarrollos se hacen más grandes, se debe complicar este tipo de diagramas, pero me resultan de gran ayuda a la hora de iniciar.
Saludos

Te ha quedado bastante bien.

Aunque no sean los símbolos de organigrama, se entiende fácil.

Lo que tiene los distintos tipos de símbolos es que puedes ver a la primera si es una entrada de datos, una operación,etc.
Como ya describes la función en el mismo bloque, aclaras toda la operación que va a realizar.

Saludos