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

Fl owcharts y pseudocode a menudo tienen el mismo nivel de expresividad, pero difieren en la linealización. El pseudocó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 tienen un nivel de abstracción más alto, se usan antes de escribir pseudocódigo o para documentación.

Los diagramas de flujo tienen, en mi opinión, dos grandes ventajas sobre el pseudocódigo: en primer lugar, son gráficos. Mucha gente no técnica tiene un gran miedo al texto estructurado, pero no a las descripciones gráficas, por lo que los diagramas de flujo les sientan mucho mejor. En segundo lugar, los diagramas de flujo son mucho mejores para expresar las meta-consideraciones, como mostrar la línea principal de ejecución en lugar de las ramas.

Sus preguntas en detalle:

1. Para un problema, primero usaría diagramas de flujo, luego pseudocódigo. Ambos son opcionales cuando se siente lo suficientemente seguro.
2. Sí, el pseudocódigo tiene la ventaja de poder fusionarse con código real. Steve McConnell, por ejemplo, recomienda encarecidamente 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 complicada, que debe evitarse a un gran costo.

Comentarios

• Los diagramas de flujo también son excelentes para asegurarse de que cada punto de decisión defina las acciones para las rutas menos comunes, así como la más común. Esto ayuda a asegurarse de que sepa qué hacer cuando se deniega la aprobación o se cancela el pedido. A menudo hay más errores en los casos extremos porque la gente se olvida de hacerlos o los hace apresuradamente durante el control de calidad cuando las pruebas los encuentran.

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 termine mi código, es el código real. Hay algunos casos en los que el pseudocódigo puede ser útil, pero generalmente estás trabajando en algo muy complejo y solo intentas desglosar la estructura de un método o algo. En esos casos, utilizo 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 por leyendo los comentarios y viendo lagunas obvias en ellos.
• Cuando completo el código real, tengo comentarios que explican en inglés lo que estoy haciendo. (Probablemente lo necesitarán si es tan complicado que necesito escribir pseudocódigo primero).

En diagramas de flujo

El código normalmente cambia tanto que los diagramas de flujo no son útiles excepto para una arquitectura más grande que abarca todo el sistema diseño o documentación. En esos casos, simplemente escribiré un diagrama en la pizarra para comprender 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 para ayudarlo a comprender, entonces realmente no los necesita para «hacer» software derecho. Hoy en día, existen muchos complementos para IDE que generarán diagramas de flujo a partir del código mismo, así como diagramas de clases y otros (y viceversa `). El único momento real que necesitaría para hacer un diagrama de flujo realmente preciso es si no puede mantener toda la arquitectura y cómo funcionan las cosas en su cabeza a la vez y necesita hablar a través de algo visual para detectar problemas.

Generalmente no escribo Diagramas de flujo mientras trabajo 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, bases de datos, interfaces manuales, etc., los diagramas de flujo son útiles.

Recomendaría Usted escribe pseudocódigo y digramas UML, ya que estas herramientas le ayudarán a encontrar mejores clases, métodos, etc. A veces, mientras escribe pseudocódigo, encontrará formas diferentes y más eficientes de resolver un programa.

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

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

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ás diseñando el programa en términos de clases y métodos, pseudo código por otro lado proporcionar un nivel más bajo de abstracción (aunque realmente depende)

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

por lo tanto, el pseudocódigo ahora se puede traducir a un programa real según el idioma que estés usando.

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

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 estado, es esencial dibujar un diagrama de máquina de estado (similar a un diagrama de flujo).
2. Creo que tiene razón aquí. Una forma de trabajar es escribir su pseudocódigo como comentarios en su archivo fuente para empezar e insertar las líneas de implementación reales entre ellos.
3. Una vez más, use lo que le resulte más cómodo. Si no está seguro, pruebe 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 Java, un buen IDE y Javadoc es 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, quizás, 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í, crea un «diagrama» más comprensible del que podría dibujar incluso una hoja de papel grande. El código Java es tan simple como cualquier pseudocódigo y mucho más riguroso. Y una vez que «lo tienes» diagramado «y» pseudo «codificado, ¡el programa realmente se ejecutará!

Comentarios

• Java y otros pueden ser prolongados. » public static void main .. » o » system.out.println » o identificadores largos con notación de camelback, prolongados allí, luego excepciones tengo 2b capturado … Y llamar a cualquier biblioteca puede ser largo. Recuerdo que hace 10 años abrí un archivo. algo como new BufferedReader (new InputStreamReader (System.in)); aparentemente más fácil ahora mkyong.com / java / … Pero, en realidad, cualquier biblioteca a la que llame podría ser larga, no como un pseudocódigo que puede ser tan conciso como pueda imaginar
• también en java o en cualquier idioma, encuentras errores en la compilación. nada de eso con pseudocódigo. puedes concentrarte en el diseño sin distracciones. Los comentarios sobre pseudocódigo pueden ser mucho más breves ya que el pseudocódigo es más claro para la mente que ‘ s de la mente. Usted ‘ no está limitado por pensar en un solo idioma, y es posible que vea que ah i ‘ usaré este otro idioma. Es ‘ es más rápido y menos doloroso de escribir (no se necesitan compilaciones, incluso los muy fluidos obtienen errores de compilación) y, por lo tanto, menos tiempo para escribir facilita el rediseño.
• @barlop: Me funciona, pero puede que no funcione para todos. Dejo mucho código (» BufferedReader «, por ejemplo) fuera de mis clases hasta que lo necesito o necesito saber si puede hacer que funcione. Incluso cuando lo tengo, ‘ está muy bien escondido en clases que no ‘ necesito tener en cuenta cuando considero en general diseño. Los errores del compilador se corrigen fácilmente y pueden evitar fallas de diseño importantes, como el uso de la clase incorrecta en un punto en el que no puede ‘ ni siquiera obtener una instancia del clase correcta. Lo admito, he » diseñado » software de esta manera que solo estar escrito en Java, pero el OP está usando Java.
• así que diga que quiere abrir un archivo, ¿ve cómo el pseudocódigo de openfile (» c: \ blah \ file «) ¿es más corto que el java para hacerlo? o que print » dfdfd » es más corto que el java para hacerlo? ‘ nunca he hecho (todavía) páginas de pseudocódigo y clases múltiples. parcialmente ‘ porque no he ‘ t escrito grandes programas en edades b) parcialmente ‘ porque No ‘ creo que lo haría, creo que ‘ d escribir un pseudocódigo y luego implementarlo. Cualquier otro pseudocódigo si lo hubiera, sería de nivel superior. Podría tener una lista de todas las clases y métodos incluyendo constructores. Entonces sé qué clases son qué y que puedo obtener una instancia de ello ..
• así que no ‘ no estaría en una situación de uso de la clase incorrecta pero de todos modos, si ‘ es mi programa, ‘ habría escrito en mis notas qué clase es qué … las clases son bonitas nivel alto. i ‘ tendría una nota al respecto si no puedo ‘ recordarlo. Y el pseudocódigo tiene que ver con lo que uno quiere decir, por lo que si pretendía hacer una instancia de clase blah y escribió bleh, entonces ‘ es solo un error de escritura pero no ‘ t obstaculice su diseño. (si ‘ estás escribiendo para ti mismo ‘ porque sabes lo que quieres decir y lo usaste como un bla).

Podrías usar un diagrama de flujo si estás realmente confundido por las declaraciones if y estás tratando de entender ese. O si está tratando de entender un bucle, vea el efecto de los contadores. Si está aprendiendo, puede ayudar mucho.

Puede parecer un poco restrictivo «porque tienes que poner declaraciones breves en cuadros. Y si tu programa es muy lineal y tus bucles e ifs son triviales, entonces no veo ningún uso para ello.

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

Por lo tanto, útiles para usted.

También se pueden usar para comunicarse con otros.