¿Con qué frecuencia usa pseudocódigo en el mundo real?

Question

De vuelta en la universidad, solo el uso del pseudo código fue evangelizado más que OOP en mi plan de estudios. Al igual que al comentar (y otras "prácticas recomendadas" predicadas), descubrí que, en el momento crucial, el psuedocode a menudo se descuidaba. Entonces mi pregunta es ... ¿quién realmente la usa mucho el tiempo? ¿O solo lo usas cuando un algoritmo es realmente difícil de conceptualizar por completo en tu cabeza? Me interesan las respuestas de todo el mundo: desarrolladores jóvenes mojados detrás de veterinarios canosos que estaban en los días de la tarjeta perforada.

En cuanto a mí personalmente, la mayoría de las veces solo lo uso para cosas difíciles.

Answer 1

Lo uso todo el tiempo. Cada vez que tenga que explicar una decisión de diseño, la usaré. Hablando con personal no técnico, lo usaré. Tiene aplicación no solo para programación, sino también para explicar cómo se hace algo.

Al trabajar con un equipo en múltiples plataformas (front-end de Java con un back-end de COBOL, en este caso) es mucho más fácil explicar cómo funciona un código de pseudocódigo que mostrar un código real.

Durante la etapa de diseño, el pseudocódigo es especialmente útil porque le ayuda a ver la solución y si es factible o no. He visto algunos diseños que se veían muy elegantes, solo para tratar de implementarlos y darme cuenta de que ni siquiera podía generar pseudocódigo. Resultó que el diseñador nunca había intentado pensar en una implementación teórica. Si hubiera tratado de escribir algún pseudocódigo que representara su solución, nunca hubiera tenido que perder 2 semanas tratando de descubrir por qué no podía hacerlo funcionar.

Answer 2

Uso el pseudocódigo cuando está lejos de una computadora y solo tengo papel y lápiz. No tiene mucho sentido preocuparse por la sintaxis del código que no se compilará (no se puede compilar el papel).

Answer 3

Principalmente utilícelo para descifrar código realmente complejo, o al explicar código a otros desarrolladores o no desarrolladores que entienden el sistema.

también diagramas de flujo y diagramas UML tipo cuando se trata de hacer más arriba también ...

Answer 4

generalmente lo uso en el desarrollo de múltiples si else anidadas, que pueden ser confusos.

De esta forma no necesito volver atrás y documentarlo ya que ya está hecho.

Answer 5

Rara vez, aunque a menudo documenta un método antes de escribir el cuerpo del mismo.

Sin embargo, si estoy ayudando a otro desarrollador con la forma de abordar un problema, a menudo escribo un correo electrónico con una solución de pseudocódigo.

Answer 6

Casi siempre lo uso hoy en día al crear rutinas no triviales. Creo el pseudo código como comentarios y sigo expandiéndolo hasta que llego al punto en que puedo escribir el código equivalente debajo de él. Descubrí que esto acelera significativamente el desarrollo, reduce el síndrome de "solo escribir código" que a menudo requiere reescribir cosas que originalmente no se consideraban, ya que lo obliga a pensar todo el proceso antes de escribir el código real, y sirve como una buena base para documentación del código después de que está escrito.

Answer 7

No uso pseudocódigo en absoluto. Estoy más cómodo con la sintaxis de los lenguajes de estilo C que con Pseudocódigo.

Lo que hago con bastante frecuencia para fines de diseño es esencialmente un estilo de descomposición funcional de la codificación.

public void doBigJob(params) 
{ 
    doTask1(params); 
    doTask2(params); 
    doTask3(params); 
} 
private void doTask1(params) 
{ 
    doSubTask1_1(params); 
    ... 
} 

Que, en un mundo ideal, eventualmente se convertiría en código de trabajo a medida que los métodos se vuelven cada vez más triviales. Sin embargo, en la vida real, hay una gran cantidad de refactorización y repensar el diseño.

Nos parece que esto funciona bastante bien, ya que rara vez encontramos un algoritmo que sea ambos: increíblemente complejo y difícil de codificar y no se resuelve mejor con UML u otra técnica de modelado.

Answer 8

Si estoy resolviendo algo complejo, lo uso mucho, pero lo uso como comentarios. Por ejemplo, archivaré el procedimiento y pondré cada paso que creo que debo hacer. Cuando escriba el código, dejaré los comentarios: dice lo que estaba tratando de hacer.

procedure GetTextFromValidIndex (input int indexValue, output string textValue) 
// initialize 
// check to see if indexValue is within the acceptable range 
// get min, max from db 
// if indexValuenot between min and max 
//  then return with an error 
// find corresponding text in db based on indexValue 
// return textValue 
    return "Not Written"; 
end procedure; 

Answer 9

Nunca, ni siquiera una vez, tuve que escribir el pseudocódigo de un programa antes de escribirlo.

Sin embargo, de vez en cuando he tenido que escribir pseudocódigo después de la escritura de código, lo que suele ocurrir cuando estoy tratando de describir la implementación de alto nivel de un programa para conseguir a alguien al día con el nuevo código en un corto cantidad de tiempo. Y por "aplicación de alto nivel", me refiero a una línea de pseudocódigo describe 50 o más líneas de C#, por ejemplo:

 
Core dumps a bunch of XML files to a folder and runs the process.exe 
    executable with a few commandline parameters. 

The process.exe reads each file 
    Each file is read line by line 
    Unique words are pulled out of the file stored in a database 
    File is deleted when its finished processing 

Ese tipo de pseudocódigo es lo suficientemente bueno para describir aproximadamente 1.000 líneas de código, y el buen suficiente para informar con precisión a un novato lo que el programa realmente está haciendo.

En muchas ocasiones, cuando no sé cómo resolver un problema, me encuentro dibujando mis módulos en una pizarra en términos de muy alto nivel para obtener una imagen clara de cómo interactúan, dibujando un prototipo de una base de datos esquema, dibujar una estructura de datos (especialmente árboles, gráficos, matrices, etc.) para obtener un buen manejo sobre cómo atravesarlo y procesarlo, etc.

Answer 10

Nunca lo uso o lo uso.

Siempre trato de hacer un prototipo en un lenguaje real cuando necesito hacer algo complejo, generalmente escribiendo pruebas unitarias primero para descubrir qué necesita hacer el código.

Answer 11

Yo y los otros desarrolladores de mi equipo lo utilizamos todo el tiempo. En correos electrónicos, pizarra, o simplemente en confersation. Psuedocode está pensado para ayudarte a pensar de la manera que necesitas, para poder programar. Si realmente resiste el psuedocode, puede conectarse con casi cualquier lenguaje de programación porque la principal diferencia entre ellos es la sintaxis.

Answer 12

Lo uso al explicar conceptos. Ayuda a recortar los bits de lenguaje innecesarios para que los ejemplos solo tengan los detalles pertinentes a la pregunta que se hace.

Lo uso bastante en StackOverflow.

Answer 13

No uso pseudocódigo como se enseña en la escuela, y no lo he hecho en mucho tiempo.

Uso descripciones en inglés de algoritmos cuando la lógica es lo suficientemente compleja como para justificarla; se llaman "comentarios".;-)

la hora de explicar las cosas a los demás, o resolver las cosas en el papel, yo uso diagramas tanto como sea posible - el más simple, en su capítulo 9, "El proceso de programación Pseudocódigo mejor

Answer 14

Steve McConnel Code Complete "propone un enfoque interesante: al escribir una función de más de unas pocas líneas, use un pseudocódigo simple (en forma de comentarios) para delinear lo que la función/procedimiento necesita hacer antes de escribir el código real que lo hace. Los comentarios de pseudocódigo pueden convertirse en comentarios reales en el cuerpo de la función.

Tiendo a usar esto para cualquier función que hace más de lo que se puede entender rápidamente al mirar una pantalla (max) de código. Funciona especialmente bien si ya se utiliza para separar el cuerpo de su función en "párrafos" de código: unidades de código semánticamente relacionado separadas por una línea en blanco. Luego, los "comentarios de pseudocódigo" funcionan como "encabezados" en estos párrafos.

PD: Algunas personas pueden argumentar que "no debe comentar qué, sino por qué, y solo cuando no es trivial para un lector que conoce el idioma en cuestión mejor que usted". Generalmente estoy de acuerdo con esto, pero hago una excepción para el PPP. Los criterios para la presencia y la forma de un comentario no deben ser inamovibles, pero en última instancia se rigen por wise, well-thought application of common sense de todos modos. Si te niegas a probar una ligera inclinación a una "regla" subjetiva por el simple hecho de hacerlo, tal vez necesites dar un paso atrás y darte cuenta si no te enfrentas a ella lo suficientemente críticamente.