Як документувати 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.