pseudocode - pseudocodigo - programas para hacer algoritmos
¿Con qué frecuencia usas pseudocódigo en el mundo real? (14)
Casi siempre lo uso hoy en día cuando creo 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.
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, solo lo uso para cosas difíciles.
En su mayoría, lo utilizan para descifrar código realmente complejo, o al explicar el código a otros desarrolladores o no desarrolladores que entienden el sistema.
También hago diagramas de flujo o diagramas tipo uml cuando intento hacer lo anterior también ...
Generalmente lo uso cuando desarrollo múltiples sentencias if else anidadas, lo que puede ser confuso.
De esta forma, no es necesario que regrese y lo documente, ya que ya está hecho.
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 .
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 usando 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.
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". ;-)
cuando explico cosas a otros, o trabajo en papel, utilizo diagramas tanto como sea posible - cuanto más simple, mejor
No uso pseudocódigo en absoluto. Me siento 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);
...
}
Lo cual, 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.
Encontramos 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 mejor resuelto usando UML u otra técnica de modelado.
Nunca lo uso o lo uso.
Siempre intento prototipar en un lenguaje real cuando necesito hacer algo complejo, generalmente escribiendo pruebas unitarias primero para descubrir qué necesita hacer el código.
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 un seudocódigo después de escribir el código, lo que generalmente sucede cuando trato de describir la implementación de alto nivel de un programa para que alguien se ponga al día con el nuevo código en un corto período de tiempo. Y por "implementación de alto nivel", quiero decir que 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 suficiente para describir aproximadamente 1000 líneas de código, y lo suficientemente bueno como para informar con precisión a un novato de lo que el programa está haciendo en realidad.
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 tener una idea clara de cómo interactúan, dibujando un prototipo de un esquema de base de datos, dibujando un estructura de datos (especialmente árboles, gráficos, matrices, etc.) para obtener un buen manejo sobre cómo atravesarlo y procesarlo, etc.
Rara vez, aunque a menudo documentar un método antes de escribir el cuerpo de la misma.
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.
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;
Utilizo pseudocódigo cuando estoy lejos de una computadora y solo tengo papel y bolígrafo. No tiene mucho sentido preocuparse por la sintaxis del código que no se compilará (no se puede compilar el papel).
Yo y los otros desarrolladores de mi equipo lo usamos 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.
El Código Completo de Steve McConnel, en su capítulo 9, "El proceso de programación de pseudocódigo" 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 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 mirando 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 deberías comentar qué, sino por qué, y solo cuando no es trivial entender para un lector que conoce el idioma en cuestión mejor que tú" . 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, sino que deben regirse por una aplicación sabia y bien pensada del sentido común . 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.