Як документувати Ruby-код?


201

Чи існують певні правила коду під час документування рубінового коду? Наприклад, у мене є такий фрагмент коду:

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

Здогадується, що це нормально, але, можливо, є кращі / покращені методи документації?


shop.oreilly.com/product/9780596516178.do має прекрасний приклад у вихідному коді. Подивіться список 2 глави. Це приблизно як відповідь тут. Я грав з rdoc просто для показу вихідного коду. Ви можете зробити своє розширення файлу чимось на зразок my_code.rb до my_code.rb.txt, а потім запустити на ньому rdoc. > rdoc my_code.rb.txt, то це не матиме значення для класів і модулів, оскільки rdoc все одно виведе HTML для нього. Повеселіться з цим.
Дуглас Г. Аллен

Відповіді:


198

Вам слід націлити свою документацію на процесор RDoc, який може знайти вашу документацію та генерувати з неї HTML. Ви розмістили свій коментар у потрібному місці для цього, але вам слід ознайомитися з документацією RDoc, щоб дізнатися про види тегів, які RDoc знає, як форматувати. З цією метою я переформатую ваш коментар наступним чином:

  # 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)

Як мені задокументувати, що параметри зовнішньої торгівлі та ерхандлера можуть бути нульовими?
StackedCrooked

10
Анотації YARD можуть бути більш потужними, але поки вони не включені в стандартний Ruby-дистрибутив замість RDoc, його анотації не є стандартними.
Кен Блум

Посилання RDoc порушено, спробуйте це: github.com/ruby/rdoc . Я прошу відредагувати відповідь, якщо всі задоволені цим посиланням.
Джордан Стюарт

27

Я б дуже рекомендував використовувати RDoc . Це майже стандарт. Прочитати коментарі до коду легко, і це дозволяє легко створювати веб-документацію для вашого проекту.


24

Я б запропонував ознайомитися з RDoc, як зазначено. Але не ігноруйте також дуже популярний інструмент YARD A Ruby Document . Багато документації, яку ви побачите в Інтернеті для Ruby використовує Ярд. RVM знає Ярд і використовує його для генерації вашої документації на вашій машині, якщо вона є в наявності.

RDoc все одно буде потрібен, оскільки Yard використовує його.


1
Використовуючи здебільшого C ++, Java, Scala та PHP, я вважаю, що @tagпозначення дуже знайомі.
sum1ejack

1
Минуло чотири роки, і ЯРД значно розвинувся. Шкода, що ЯРД досі не входить до складу Рубі. (До речі, домашня сторінка YARD приймає HTTPS.)
Франклін Ю

1
Двір, здається, легший за RDoc! Дякую :)
Константин Де Ла Рош


9

Ви також можете перевірити TomDoc на Ruby - Версія 1.0.0-rc1.

http://tomdoc.org/


FWIW, ця інформація вказана у посібнику зі стилю GitHub - github.com/styleguide/ruby
Michael Easter

Дякую, tomdoc, здається, є хорошим джерелом для найкращих сучасних практик, коли справа стосується документування коду рубіну. Відповідає на "як" і "чому", що, очевидно, відсутнє в документації на rdoc.
Майкл Реннер

TomDoc не оновлювався. Останній Комміт був травень 2012 року
maasha

1
@maasha До 2017 року я вважаю, що найкращою ставкою, крім простого RDoc, буде YARD, тепер він аналізує вміст і робить деякі химерні гіперпосилання на класи та методи.
Франклін Ю

2

Канонічний - RDoc, він дуже схожий на той, який ви розмістили.

Дивіться зразок розділу за посиланням, яке я вам надіслав


Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.