¿Cuándo usaría pseudocódigo en lugar de diagrama de flujo?

Soy un estudiante que trabaja con varias técnicas de programación, y me he encontrado con pseudocódigo y diagrama de flujo. Sé que ambos se usan para reflexionar sobre el problema antes de programar realmente, pero tengo algunas preguntas al respecto.

1. ¿Cuándo usaría pseudocódigo para planificar y cuándo usaría diagramas de flujo? ¿O es mejor hacer ambas cosas antes de programar realmente? Particularmente para un pequeño tipo de juego de arcade en JAVA ya que ese es mi próximo proyecto.
2. Me di cuenta de que el pseudocódigo es muy similar al código real en lugar de los diagramas de flujo. ¿Esto mejoraría la pseudocodificación porque esencialmente copie / pegue el pseudocódigo en su programa (por supuesto, tiene que cambiarlo para que se ajuste al idioma. Entiendo esa parte).
3. ¿Es práctico usar ambos durante la programación? Particularmente el mismo juego mencionado anteriormente. Gracias.

Los diagramas de flujo y el seudocódigo a menudo tienen el mismo nivel de expresividad, pero difieren en la linealización. El seudocódigo es lineal (es decir, una secuencia de líneas con instrucciones), un diagrama de flujo no lo es. Por lo tanto, los diagramas de flujo son un nivel de abstracción más alto, que se usa antes de escribir pseudocódigo o para documentación.

Los diagramas de flujo tienen, en mi opinión, dos fuertes ventajas sobre el pseudocódigo: en primer lugar, son gráficos. Muchas personas no técnicas tienen un fuerte temor al texto estructurado, pero no a las descripciones gráficas, por lo que los diagramas de flujo les resultarán mucho más agradables. En segundo lugar, los diagramas de flujo son mucho mejores para expresar metaconsideraciones, como mostrar la línea principal de ejecución en lugar de las ramas.

Sus preguntas en detalle:

1. Para un problema realmente complicado, primero usaría diagramas de flujo, luego pseudocódigo. Ambos son opcionales cuando te sientes lo suficientemente seguro.
2. Sí, el pseudocódigo tiene la ventaja de ser fusionable con código real. Steve McConnell, por ejemplo, recomienda enfáticamente escribir métodos en pseudocódigo primero y luego dejar el pseudocódigo en el código como comentarios.
3. Siempre sentí que la necesidad de dibujar un diagrama de flujo durante el diseño muestra una partición insuficiente de su problema. Los diagramas de flujo no triviales indican una lógica enrevesada, que debe evitarse a grandes costos.

En pseudocódigo

Para ser honesto, no uso mucho el pseudocódigo. Por lo general, es más rápido escribir el código, de modo que cuando haya terminado con mi código, sea el código real. Hay algunos casos en los que el pseudocódigo puede ser útil, pero generalmente está trabajando en algo muy complejo y solo está tratando de descomponer la estructura de un método o algo. En esos casos, uso comentarios en mi IDE para diseñar la estructura hasta que haga las cosas bien. Luego, entro y escribo el código real en los comentarios. Esto me ayuda a hacer algunas cosas:

• Puedo ver áreas que tengo y no he implementado al leer los comentarios y ver lagunas obvias en ellos.
• Cuando complete el código real, tengo comentarios que explican en inglés lo que estoy haciendo. (Probablemente lo necesitarán si es tan complicado que primero necesito escribir un pseudocódigo).

En diagramas de flujo

El código generalmente cambia tanto que los diagramas de flujo no son útiles, excepto por un diseño o documentación de arquitectura más grande y más amplio para todo el sistema. En esos casos, solo haré una pizarra con un diagrama para obtener la esencia de las cosas o para mostrárselo a alguien más en el equipo. A menos que realmente necesite un diagrama de flujo que lo ayude a comprender, entonces realmente no necesita que "hagan" correctamente el software. Hoy en día, hay muchos complementos para IDE que generarán diagramas de flujo del código en sí, así como diagramas de clases y otros (y viceversa `). El único momento real en el que necesitaría hacer un diagrama de flujo realmente preciso es si no puede mantener toda la arquitectura y cómo las cosas funcionan en su cabeza de una vez y necesita hablar sobre algo visual para atrapar problemas.

En general, no escribo diagramas de flujo mientras estoy trabajando en proyectos personales (ya que los proyectos no son muy grandes) y la mayoría de las entradas, salidas y procesos son claros.

pero como comenzará a trabajar en grandes proyectos complejos con diferentes fuentes de entrada, los archivos planos, las bases de datos, las interfaces manuales, etc., son útiles.

Te recomendaría escribir Pseudocódigo y digramas UML ya que estas herramientas te ayudarán a encontrar mejores clases, métodos, etc. A veces, mientras escribes pseudocódigo, encontrarás formas diferentes y más eficientes de resolver un programa.

El pseudocódigo es para representar rápidamente una idea para aquellos que entienden al menos los conceptos básicos del código. Los diagramas de flujo están dibujando imágenes bonitas para que todos los demás entiendan lo mismo.

Los diagramas de flujo a menudo se usan con fines de documentación porque muchas personas diferentes usan esa documentación y los diagramas de flujo son más fáciles de seguir que el pseudocódigo para los no programadores. En un proyecto en el que está trabajando, seguir con el pseudocódigo está bien, ya que es mucho más útil y mucho más fácil de crear, ya que un editor de texto es todo lo que necesita.

Los diagramas de flujo son un alto nivel de abstracción que le permiten planificar cómo deben proceder las cosas, por ejemplo

si x muere y gana

No necesitan depender de cómo está diseñando el programa en términos de clases y métodos, el pseudocódigo, por otro lado, proporciona un menor nivel de abstracción (aunque realmente depende)

if (isdead (s)) y.win ()

así, el pseudocódigo ahora se puede traducir al programa real en función del idioma que esté utilizando.

Para un juego, recomendaría usar primero un diagrama de flujo, luego diseñar las clases y métodos, escribir un pseudocódigo y finalmente convertirlo en un programa

Consideraría la naturaleza del código que está escribiendo. Si esto es:

1. Altamente iterativo / recursivo
2. Ramas de formas complicadas
3. Implementado en varios sistemas, que desea representar

En los primeros dos casos, el pseudocódigo se vuelve cada vez más difícil de leer que un diagrama de imagen grande. Por otro lado, el código que es principalmente lineal crea diagramas increíblemente aburridos que en realidad hacen que el proceso sea más difícil de entender debido a cuánto lo explota.

Para el tercer caso, los diagramas de flujo son mejores para representar procesos que cruzan los límites del sistema y representan todo el proceso.

1. Debe usar lo que le resulte más cómodo. Dicho esto, mi impresión es que los diagramas de flujo no se utilizan mucho para esbozar el control del programa en estos días; por un lado, generalmente no están estructurados, en comparación con el pseudocódigo. Es más común usar diagramas de dependencia de clases como UML, para describir su arquitectura en un nivel mucho más alto. Además, si su aplicación tiene una máquina de estados, es esencial dibujar un diagrama de máquina de estados (similar a un diagrama de flujo).
2. Creo que tienes razón aquí. Para empezar, una forma de trabajar es escribir su pseudocódigo como comentarios en su archivo fuente e insertar las líneas de implementación reales entre ellos.
3. Nuevamente, use lo que le resulte más cómodo. Si no está seguro, pruébelos a ambos; Espero que su práctica converja rápidamente en lo que sea más útil para usted. Personalmente, no encuentro útiles los diagramas de flujo a menos que esté tratando de desenredar una orden de ejecución particularmente complicada.

¿Por qué escribir pseudocódigo cuando puedes escribir Java? He encontrado que Java, un buen IDE y Javadoc son la forma más fácil de comprender un problema de programación, al menos uno orientado a objetos . (Y un juego de arcade debería ser OO). El lenguaje fue diseñado desde cero para esto. Es simple y directo. (Demasiado simple para muchos propósitos, tal vez, pero lo mejor que he visto para esto.) El hipertexto en el Javadoc y, a través de un IDE, en el código en sí mismo hacen un "diagrama" más comprensible de lo que podrías dibujar incluso una hoja grande de papel El código Java es tan simple como cualquier pseudocódigo y mucho más riguroso. Y una vez que lo haya "diagramado" y "pseudo" codificado, ¡el programa realmente se ejecutará!

Podría usar un diagrama de flujo si se está confundiendo realmente con las declaraciones if y está tratando de entender eso. O si está tratando de entender un ciclo, vea el efecto de los contadores. Si estás aprendiendo, puede ayudar mucho.

Puede parecer un poco restrictivo porque tienes que poner breves declaraciones en cuadros. Y si su programa es muy lineal y sus bucles y ifs son triviales, entonces no veo ninguna utilidad.

El pseudocódigo es útil para diseñar un programa, sin la distracción de tener que tener la sintaxis correcta y sin el largo aliento que pueden implicar algunos lenguajes. El hecho de que sea más rápido de escribir también facilita el rediseño del código. Y puede ser tan conciso como lo desee su mente, es agradable escribir, requiere menos esfuerzo mental para que funcione (como no o mucho menos depuración) y más capacidad para enfocarse en el panorama general y el diseño.

Entonces, útil para ti.

También se pueden usar para comunicarse con otros.