2009-11-05 31 views
165

¿Existen ciertas convenciones de código al documentar el código ruby? Por ejemplo, tengo el siguiente fragmento de código:¿Cómo se documenta el código de Ruby?

require 'open3' 

module ProcessUtils 

    # Runs a subprocess and applies handlers for stdout and stderr 
    # Params: 
    # - command: command line string to be executed by the system 
    # - outhandler: proc object that takes a pipe object as first and only param (may be nil) 
    # - errhandler: proc object that takes a pipe object as first and only param (may be nil) 
    def execute_and_handle(command, outhandler, errhandler) 
    Open3.popen3(command) do |_, stdout, stderr| 
     if (outhandler) 
     outhandler.call(stdout) 
     end 
     if (errhandler) 
     errhandler.call(stderr) 
     end 
    end 
    end 
end 

Supongo que está bien, pero tal vez hay mejores/mejores prácticas de documentación?

+0

http://shop.oreilly.com/product/9780596516178.do tiene un bonito pequeño ejemplo en el código fuente. Mire en el listado del capítulo 2. Es como la respuesta aquí. He jugado con rdoc solo para mostrar el código fuente. Puedes hacer que tu extensión de archivo sea algo así como my_code.rb en my_code.rb.txt y luego ejecutar rdoc en él. > rdoc my_code.rb.txt, entonces no importará las clases y módulos porque rdoc lo renderizará html de todos modos. Diviértete con eso. –

Respuesta

164

Debe orientar su documentación para el procesador RDoc, que puede encontrar su documentación y generar HTML a partir de ella. Ha puesto su comentario en el lugar correcto para eso, pero debería echarle un vistazo al RDoc documentation para conocer los tipos de etiquetas que RDoc sabe cómo formatear. Con ese fin, me gustaría volver a formatear el comentario de la siguiente manera:

# Runs a subprocess and applies handlers for stdout and stderr 
    # Params: 
    # +command+:: command line string to be executed by the system 
    # +outhandler+:: +Proc+ object that takes a pipe object as first and only param (may be nil) 
    # +errhandler+:: +Proc+ object that takes a pipe object as first and only param (may be nil) 
+0

¿Cómo debo documentar que los parámetros del manejador de salida y del manejador de errores pueden ser nulos? – StackedCrooked

+7

Las anotaciones de YARD pueden ser más potentes, pero hasta que se incluyan en la distribución estándar de Ruby en lugar de hacerlo en RDoc, sus anotaciones no son el estándar. –

+0

El enlace de RDoc está roto intente esto: https://github.com/ruby/rdoc. Pediré editar la respuesta si todos están contentos con ese enlace. –

2

La canónica es RDoc es muy similar a la que ha publicado.

Véase la sección de la muestra en el enlace que le envió

24

Me altamente sugiere emplear RDoc. Es más o menos el estándar. Es fácil leer los comentarios del código y le permite crear fácilmente documentación basada en la web para su proyecto.

8

También puede comprobar TomDoc para Ruby - Versión 1.0.0-RC1.

http://tomdoc.org/

+0

FWIW, este está especificado en la guía de estilo de GitHub - https://github.com/styleguide/ruby –

+0

Gracias, tomdoc parece ser una buena fuente para las mejores prácticas actuales a la hora de documentar el código de ruby. Responde el "cómo" y el "por qué" que aparentemente falta en la documentación de rdoc. –

+0

TomDoc no se ha actualizado. El último compromiso fue en mayo de 2012. – maasha

16

Yo sugeriría conocer RDoc como se dice. Pero no ignore la muy popular herramienta YARD A Ruby Document, también. Gran parte de la documentación que verá en línea para Ruby usa Yard. RVM conoce a Yard y lo usa para generar su documentación en su máquina si está disponible.

RDoc todavía se requerirá, ya que Yard lo usa.

+1

Habiendo usado principalmente C++, Java, Scala y PHP, la notación '@ tag' me resulta muy familiar. – doub1ejack

+0

Han pasado cuatro años y YARD ha evolucionado mucho.Es una pena que YARD todavía no esté incluido en Ruby. (Por cierto, la página principal de YARD acepta HTTPS). –

Cuestiones relacionadas