2008-10-20 21 views
9

Literate programming es una forma de desarrollar software donde la documentación es lo primero, luego la codificación. Uno escribe la documentación de un fragmento de código y luego escribe la implementación del fragmento. La apariencia visual del código fuente del software sería un documento simple como palabra, con párrafos de código en él.Programación alfabetizada

Estoy tratando de convertir la tienda de desarrollo con la que trabajo para usar solo la programación de escritura, ya que ofrece grandes ventajas para la legibilidad y el mantenimiento del código. Sin embargo, debido a la falta de herramientas, el uso de LP es limitado en la empresa. Por ejemplo, la forma ideal de alfabetizar el programa es escribir un párrafo utilizando el marcado de palabras, y luego insertar un subpárrafo con la implementación. Pero parece que no puedo encontrar ninguna herramienta buena para VS200x para realizar LP.

Idealmente, esta herramienta se vería igual que Word 2007, pero integrada en el IDE. Cuando el codificador coloca el cursor en un párrafo de código, tendría toda la funcionalidad provista tal como lo tenemos ahora en nuestro IDE.

¿Cuáles son las buenas herramientas para LP, con .NET y VS200x en particular?

+9

En mi experiencia, demasiados codificadores son demasiado analfabetos para que este enfoque funcione. – MusiGenesis

+0

¿Cuánto tiempo tiene en cuenta para hacer LP ... la wiki no tiene una lista de proyectos que realmente hicieron LP y salieron a tiempo? parece una cosa más de Knuth a la que la mayoría de los mortales no se acercarán. – Gishu

+0

Es realmente una forma de escribir una especificación, ¡excepto por lo general más útil! – kyoryu

Respuesta

6

Solo puedo sugerir que marques tu código con doxygen comentarios, luego puedes generar la documentación de tu código, que sé que es casi una forma de hacer lo que quieras, pero al menos terminas con el resultado deseado : código y documentación que proviene de los mismos archivos fuente. Obviamente, esto tiene la ventaja de que utiliza su IDE existente para la codificación que viene con todas las golosinas usuales de código habituales.

Si está tratando de convertir su equipo de desarrollo, este enfoque podría ser más fácil de tragar que una metodología de alfabetización en toda regla, todavía están contentos con la codificación que es la misma, pero tienen que escribir mejor documentación incrustada en el código.

Eso es lo mejor que puedo sugerir, vea lo que su equipo piensa de la idea.

+1

Doxygen es fantástico para darle una idea del código complejo e interdependiente . – endian

+0

//, no es tan bueno eliminar el * need * para una visión no intuitiva del código complejo e interdependiente. Ahí es donde entra en juego la programación de alfabetización. –

2

El único lenguaje no esotérico que conozco que realmente tiene soporte para LP es Haskell, y para ser honesto, no he escuchado mucha demanda de LP en los lenguajes de programación modernos. La mayoría de las personas parecen estar satisfechas con el uso de formatos de documentación en línea (javadoc, rdoc, etc.)

+4

La mayoría de las personas no son programadores muy brillantes. –

+4

Corrección: la mayoría de los programadores no son programadores muy brillantes. :-) – JesperE

+2

Más precisamente, la mitad de los programadores en el mundo están por debajo del promedio –

1

Mis disculpas. Debería haber mencionado que ya estamos usando Doxygen con un script automatizado de compilación de documentos. Usamos las etiquetas de doc .NET siempre que es posible, y donde las etiquetas de doc .NET XML se quedan cortas, mezclamos las etiquetas doxygen. Esto funciona bastante bien El punto es que la producción disminuye bastante al escribir documentación: Nosotros (los humanos) somos muy malos en la producción de documentación sin ningún editor WYSIWYG. Sin mencionar error sensible.

El equipo se encuentra actualmente en la fase para convertir el modo de pensar de la codificación directamente a la primera documentación de escritura, luego codifique. Este es el paso más importante, ya que permite a los codificadores adoptar el paradigma LP.

Aquí hay un mercado para un plugin de VS que lo hace, supongo.

Además, Doxygen parece ser una buena herramienta para utilizar activamente la solución del método LP para este problema. Aunque es muy limitado en uso.

11

Felicitaciones por tratar de mejorar la forma en que trabaja su equipo. Mientras intente hacer eso, tiene una ventaja sobre aquellos que no lo hacen.

Utilicé Literate Programming para un proyecto una vez. Fue realmente difícil y los resultados fueron realmente buenos. Parecía una compensación razonable.

Sin embargo, hoy preferiría tener un enfoque diferente: en lugar de prosa para humanos y código para máquinas, prefiero escribir un código que sea tan claro que a los humanos no les importe leerlo. Cuando siento la necesidad de escribir un comentario, creo que "podría aclarar este código". Eso significa que estoy escribiendo menos documentación, no más.

Bueno, buena suerte con cualquier camino que elijas.

+0

Me parece que una manera práctica y sucia de hacerlo es extraer productos a una función separada. Si quiere escribir '// Primero, obtenga la entrada del usuario', reemplace todo con' GetUserInput() '. Si desea escribir '// Esto cómo funciona ...' dentro de un cuerpo de la función, extraerlo a 'MagicalMathFormula()' con un bloque de comentarios por funciones para una explicación (que se hace extrae bien con Doxygen) – kizzx2

+0

Sí, la mayoría Los comentarios a nivel de declaración y expresión se pueden transformar en nombres de función con Método de extracción. ¡Ahora tienes demasiadas funciones! Encuentra datos y funciones que están relacionadas, y extrae la clase. ¡Muy pronto estarás haciendo OOP! –

1

Sin embargo, hoy prefiero tener un enfoque diferente: en lugar de prosa para humanos y código para máquinas, prefiero escribir un código que sea tan claro que a los humanos no les importe leerlo. Cuando siento la necesidad de escribir un comentario, creo que "podría aclarar este código". Eso significa que estoy escribiendo menos documentación, no más.

Eso es lo que hacemos también. Aunque para un gran número de código que producimos, escribir código claro, legible para humanos simplemente no es suficiente. ¿Qué pasa si quieres explicar una función de renderizado de imágenes? Mejor explicarlo usando una imagen, en lugar de escribir media página describiéndolo.

+1

Debe escribir un documento técnico con imágenes y fórmulas TeX que expliquen cómo funciona, luego coloque un puntero en los comentarios al mismo. - La mayoría de las veces el puntero puede que ni siquiera se necesite, si su función tiene el nombre correcto, p. 'PeterJohnMaryTransform()' entonces solo necesitas una página de doc nombrada y el usuario la buscará él mismo. – kizzx2

+0

//, me gusta que parezca ver la programación como el dispositivo y la implementación de un marco conceptual correcto, en lugar de "cosas que le digo a la computadora que haga". Ambos son técnicamente correctos, pero uno incluye un horizonte fenomenológico más amplio, @ user29688. Voto otorgado. –

4

1 para tratar de mejorar el proceso de su equipo

-1 para ir por un camino sin salida

con el debido respeto a Knuth, pruebas unitarias son mejores que la documentación

  • las pruebas unitarias no pueden volverse obsoletas
  • contaminar el código con prosa es una gran distracción al depurar
  • si su código realmente requiere s esa mucha exposición, es probable que esté mal diseñada y con errores
+4

Heh. En cuanto a "las pruebas unitarias no pueden estar desactualizadas", acabo de pasar toda la mañana tratando de hacer que mis antiguas pruebas unitarias se vinculen con un proyecto de trabajo por contrato que otra persona modificó sin verificar mis pruebas. – Sol

+0

@ [colomon.livejournal.com]: doble je - si ha tenido lugar la documentación de la unidad de pruebas, sólo podía ignorarlo ... y luego más tarde que realmente te puede atornillar ;-) –

+0

Parece que una gran cantidad de disciplina es necesario ... antes que nada hacer LP. y luego, para mantener los fragmentos de LP con cada cambio en el código ... – Gishu

1

No conozco ninguna herramienta moderna para la Programación Literate. He hecho algo de programación WEB hace 15 años.

Doxygen es una buena herramienta, pero no ayuda en absoluto con LP. El problema es que LP se enfoca en escribir códigos para que los humanos los lean. No hay un buen soporte para el refinamiento/revelación sucesiva. LP necesita una vista del código fuente que tenga una estructura diferente a la clase de archivo-atributo/método en VS. NSpec podría ser algo mejor, pero también es demasiado ascendente.

0

Hola novedosos fuente autores,

Como alguien que se refiere Doxygen aquí: aunque esto no permite reales Literate Programación(como un ejemplo de las limitaciones, lo que no permite tener una visión reordenado en fuentes), que sin embargo parece ser reconocido como un valioso herramientas en esta área, por sus propios defensores (defensores LP): se menciona a la derecha en la parte superior de esta página de referencia sobre las herramientas de LP: Literate Programming Tools

0

La idea principal de la programación alfabetizada es escribir programas como textos matemáticos. Uno puede definir lo que significa cada concepto que se necesita en el programa lo más claro posible, luego explicar cómo se implementa en el lenguaje y por qué uno decidió hacerlo de esa manera y no de otra manera o de lo que se va a cambiar más adelante.

Los cambios también se pueden documentar comentando la pieza de código para cambiar e insertar la nueva que explica el motivo del cambio. Algunos cambios pueden depender de las transformaciones del código para optimizar su rendimiento. Por ejemplo, hacer un bucle, en lugar de 2 bucles en algún lenguaje C, cambiar una expresión por una más simple, etc. O algo más complejo como cambiar otra estructura de datos para representar información. Cada cambio está bien justificado y documentado. Uno puede comprender el problema del dominio del programa, simplemente leyendo el código fuente, entendiéndolo en profundidad. Evitando errores debido a ambigüedades. La génesis del programa está completamente documentada, uno puede recordar todo más tarde, porque cada pensamiento está en el programa.

Estrictamente hablando, se pueden escribir programas alfabetizados con texto plano, si el programa está desarrollado, pero escribirlo en TeX/LaTeX es la forma más estética, funcional y sencilla, porque no es difícil ubicar la marca LaTeX entre los más lenguajes de programación.

Es natural escribir programas alfabetizados en Haskell, porque una secuencia de comandos Haskell contiene un conjunto de declaraciones, no de instrucciones. Puede colocar todas las declaraciones en cualquier orden. Eso es diferente en otros idiomas donde es importante ordenar las instrucciones de una manera particular.

No he usado web ni cweb o programas similares, pero esos programas ayudan a componer los programas en un orden lógico para un ser humano, mientras que los módulos del programa se pueden generar para una compilación adecuada.

Hay un paquete LaTeX llamada listados que es fácil de usar se puede empezar cada pieza de código de cerrar el comentario y terminando el código de abrir un nuevo comentario, por lo que yo recuerdo, algo como esto:

% /* begin of literate program 
\documentstyle{article} 
\usepackage{listings} 

\lstdefinitions here I do not remember the syntax. Here one can define 
       a replacement for startcode*/ and /*endcode for spaces. 

more definitions here 

\begin{document} 
Your explanation including formulas like $s=c\times\sum_{i=0}^{i=N} x_i$ etc. 
\begin{lstlising} 
startcode*/ 

s=0 
for(i=0;i<=N;i++) s=s+x[i]; 
s=c*s; 

etc.. 

/*endofcode 
\end{lstlisting} 

More explanation ... 
\end{document} 
% end of literate program */ 

en el preámbulo del texto puede definir el código de inicio */y/* endofcode como palabras clave para reemplazar por espacios en las definiciones adicionales para el paquete de listados. Ver la documentación del paquete.

al final de la fuente LaTeX simplemente escriba:

% end of literate program */ 

que es un comentario en LaTeX en un principio se puede colocar el contrario:

% /* start of program 

Extracción del látex comentario signo% cuando desee compilar el programa y ponerlo de nuevo cuando compile LaTeX.

Si nunca antes ha usado LaTeX, primero puede comenzar con texto sin formato. Quizás combinándolo con doxigen para indexar todo. Doxigen no es necesario con LaTeX porque es un sistema de composición tipográfica, donde puede crear varios índices, hipervínculos, estructurar la documentación como un libro.

Los programas de Haskell generalmente se escriben en estilo alfabetizado. Tal vez sea una buena idea buscar un libro o artículo para ver uno.