edge
Daugiau informacijos rubyonrails.org: Daugiau apie Ruby on Rails

API Dokumentacijos Gairės

Šiame vadove dokumentuojamos Ruby on Rails API dokumentacijos gairės.

Po šio vadovo perskaitymo žinosite:

1 RDoc

Rails API dokumentacija generuojama naudojant RDoc. Norėdami ją sugeneruoti, įsitikinkite, kad esate Rails šakninėje direktorijoje, paleiskite bundle install ir vykdykite:

$ bundle exec rake rdoc

Sugeneruoti HTML failai rasomi ./doc/rdoc direktorijoje.

PASTABA: Norint gauti pagalbą dėl sintaksės, prašome pasikonsultuoti su RDoc Markup Reference.

2 Nuorodos

Rails API dokumentacija nėra skirta peržiūrėti GitHub'e, todėl nuorodos turėtų naudoti RDoc link žymėjimą atsižvelgiant į esamą API.

Tai yra dėl skirtumų tarp GitHub Markdown ir sugeneruoto RDoc, kuris yra publikuojamas adresu api.rubyonrails.org ir edgeapi.rubyonrails.org.

Pavyzdžiui, naudojame [link:classes/ActiveRecord/Base.html] nuorodą į ActiveRecord::Base klasę, sugeneruotą RDoc.

Tai yra pageidautina nei absoliučios nuorodos, pvz., [https://api.rubyonrails.org/classes/ActiveRecord/Base.html], kuri išvestų skaitytoją iš dabartinės dokumentacijos versijos (pvz., edgeapi.rubyonrails.org).

3 Formulavimas

Rašykite paprastus, deklaratyvius sakinio struktūras. Trumpumas yra pliusas: pereikite prie esmės.

Rašykite dabarties laiku: "Gražina hash'ą, kuris...", o ne "Gražino hash'ą, kuris..." arba "Gražins hash'ą, kuris...".

Komentarus pradėkite didžiąja raide. Laikykitės įprastų skyrybos taisyklių:

# Deklaruoja atributo skaitytuvą, kuris remiasi viduje pavadintu
# kintamuoju.
def attr_internal_reader(*attrs)
  # ...
end

Skaitytojui perteikite dabartinį veikimo būdą, tiek aiškiai, tiek neaiškiai. Naudokite rekomenduojamus idiomus. Jei reikia, pertvarkykite skyrius, kad būtų pabrėžti pageidaujami požiūriai ir pan. Dokumentacija turėtų būti modelis geriausioms praktikoms ir kanoniškam, moderniam Rails naudojimui.

Dokumentacija turi būti trumpa, bet išsamiai. Ištyrinkite ir aprašykite ribinius atvejus. Kas nutinka, jei modulis yra anoniminis? Kas nutinka, jei kolekcija yra tuščia? Kas nutinka, jei argumentas yra nil?

Rails komponentų pavadinimai turi tarpą tarp žodžių, pvz., "Active Support". ActiveRecord yra Ruby modulis, o Active Record yra ORM. Visos Rails dokumentacijos turėtų nuosekliai nuorodyti į Rails komponentus pagal jų tikrus pavadinimus.

Kalbant apie "Rails aplikaciją", priešingai nei "engine" ar "plugin", visada naudokite "application". Rails aplikacijos nėra "paslaugos", nebent konkretaus aptariamojo paslaugų orientuoto architektūros atveju.

Rašykite pavadinimus teisingai: Arel, minitest, RSpec, HTML, MySQL, JavaScript, ERB, Hotwire. Jei abejojate, prašome pasitikrinti autoritetingą šaltinį, pvz., jų oficialią dokumentaciją.

Pirmenybę teikite formulavimui, kuriame nėra "you" ir "your". Pavyzdžiui, vietoj

If you need to use `return` statements in your callbacks, it is recommended that you explicitly define them as methods.

naudokite šį stilių:

If `return` is needed, it is recommended to explicitly define a method.

Tačiau, naudojant įvardžius atsižvelgiant į hipotetinį asmenį, pvz., "vartotojas su sesijos slapukais", reikėtų naudoti lyties neutralius įvardžius (they/their/them). Vietoje:

  • he arba she... naudokite they.
  • him arba her... naudokite them.
  • his arba her... naudokite their.
  • his arba hers... naudokite theirs.
  • himself arba herself... naudokite themselves.

4 Anglų kalba

Prašome naudoti Amerikos anglų kalbą (color, center, modularize, ir pan.). Žr. čia Amerikos ir Britų anglų kalbos rašybos skirtumų sąrašą.

5 Oxford kablelis

Prašome naudoti Oxford kablelį ("red, white, and blue", o ne "red, white and blue").

6 Pavyzdžio kodas

Pasirinkite prasmingus pavyzdžius, kurie atspindi ir apima pagrindinius dalykus bei įdomius momentus ar klaidas.

Kodo gabalams įrėminti naudokite dvi tarpas--tai yra, žymint žymėjimo tikslais, dvi tarpas atsižvelgiant į kairįjį kraštinę. Patys pavyzdžiai turėtų naudoti Rails kodavimo konvencijas.

Trumpiems dokumentams nereikia aiškiai nurodyti "Pavyzdžiai" žymės, kad būtų įterpti fragmentai; jie tiesiog seka po pastraipų:

# Converts a collection of elements into a formatted string by
# calling +to_s+ on all elements and joining them.
#
#   Blog.all.to_fs # => "First PostSecond PostThird Post"

Kita vertus, dideliems struktūruotiems dokumentams gali būti atskiras "Pavyzdžiai" skyrius:

# ==== Examples
#
#   Person.exists?(5)
#   Person.exists?('5')
#   Person.exists?(name: "David")
#   Person.exists?(['name LIKE ?', "%#{query}%"])

Rezultatai išraiškų seka juos seka ir pristatoma "# => ", vertikaliai išlyginta:

# Tikrinant, ar sveikasis skaičius yra lyginis ar nelyginis.
#
#   1.even? # => false
#   1.odd?  # => true
#   2.even? # => true
#   2.odd?  # => false

Jei eilutė per ilga, komentaras gali būti perkeltas į kitą eilutę:

#   label(:article, :title)
#   # => <label for="article_title">Title</label>
#
#   label(:article, :title, "A short title")
#   # => <label for="article_title">A short title</label>
#
#   label(:article, :title, "A short title", class: "title_label")
#   # => <label for="article_title" class="title_label">A short title</label>

Vengti naudoti spausdinimo metodus, pvz., puts ar p, tam tikslui.

Kita vertus, įprasti komentarai nenaudoja rodyklės:

#   polymorphic_url(record)  # tas pats kaip comment_url(record)

6.1 SQL

Dokumentuojant SQL teiginius, rezultatas neturi turėti => prieš išvestį.

Pavyzdžiui,

#   User.where(name: 'Oscar').to_sql
#   # SELECT "users".* FROM "users"  WHERE "users"."name" = 'Oscar'

6.2 IRB

Dokumentuojant elgesį su IRB, Ruby interaktyviu REPL, visada prieš komandas naudokite prefiksą irb> ir išvestis turi būti su prefiksu =>.

Pavyzdžiui,

# Rasti klientą su pagrindiniu raktu (id) 10.
#   irb> customer = Customer.find(10)
#   # => #<Customer id: 10, first_name: "Ryan">

6.3 Bash / komandinė eilutė

Komandinės eilutės pavyzdžiams visada prieš komandą naudokite $, išvestis neturi turėti jokio prefikso.

# Paleiskite šią komandą:
#   $ bin/rails new zomg
#   ...

7 Booleans

Predikatuose ir vėliavose pageidautina dokumentuoti boolean semantiką, o ne tikslų reikšmes.

Kai "true" arba "false" naudojami, kaip apibrėžta Ruby, naudokite įprastą šriftą. Vienetiniai true ir false reikalauja fiksuoto pločio šrifto. Prašome vengti terminų, tokio kaip "truthy", Ruby apibrėžia, kas yra tiesa ir netiesa kalboje, todėl šie žodžiai turi techninį prasmės ir nereikalauja jokių pakaitų.

Taisyklės pagalba nereikia dokumentuoti vienetinių, nebūtina. Tai neleidžia dirbtiniams konstruktams, tokiam kaip !! ar ternariniai operatoriai, leidžia atlikti pertvarkymus ir kodas neturi remtis tiksliais grąžinamų metodų reikšmėmis, kurie yra iškviesti įgyvendinime.

Pavyzdžiui:

`config.action_mailer.perform_deliveries` nurodo, ar paštas iš tikrųjų bus pristatomas ir pagal numatytuosius nustatymus yra tiesa

vartotojui nereikia žinoti, kokia yra vėliavos numatytoji reikšmė, todėl dokumentuojame tik jos boolean semantiką.

Pavyzdys su predikatu:

# Grąžina true, jei kolekcija yra tuščia.
#
# Jei kolekcija yra įkelta
# tai yra lygu <tt>collection.size.zero?</tt>. Jei
# kolekcija nebuvo įkelta, tai yra lygu
# <tt>!collection.exists?</tt>. Jei kolekcija dar nebuvo
# įkelta ir jūs vis tiek ketinate gauti įrašus, geriau
# patikrinkite <tt>collection.length.zero?</tt>.
def empty?
  if loaded?
    size.zero?
  else
    @target.blank? && !scope.exists?
  end
end

API atsargus neprisiima jokios konkretaus reikšmės, metodas turi predikato semantiką, tai pakanka.

8 Failų pavadinimai

Taisyklės pagalba naudokite failų pavadinimus, susijusius su programos šaknimi:

config/routes.rb            # TAIP
routes.rb                   # NE
RAILS_ROOT/config/routes.rb # NE

9 Šriftai

9.1 Fiksuoto pločio šriftas

Naudokite fiksuoto pločio šriftus:

  • Konstantoms, ypač klasės ir modulio pavadinimams.
  • Metodų pavadinimams.
  • Literalomis, tokiais kaip nil, false, true, self.
  • Simboliais.
  • Metodų parametrais.
  • Failų pavadinimais.
class Array
  # Iškviečia +to_param+ visuose savo elementuose ir sujungia rezultatą su
  # pasviraisiais brūkšniais. Tai naudojama +url_for+ veiksmo pakete.
  def to_param
    collect { |e| e.to_param }.join '/'
  end
end

ĮSPĖJIMAS: Naudoti +...+ fiksuoto pločio šriftui veikia tik su paprastu turiniu, tokiais kaip įprastos klasės, modulio, metodo pavadinimai, simboliai, keliai (su įstrižainėmis brūkšneliais) ir kt. Prašome naudoti <tt>...</tt> visam kitam turiniui.

RDoc išvestį galite greitai patikrinti naudodami šią komandą:

$ echo "+:to_param+" | rdoc --pipe
# => <p><code>:to_param</code></p>

Pavyzdžiui, kodas su tarpais ar kabutėmis turėtų naudoti formą <tt>...</tt>.

9.2 Įprastas šriftas

Kai "true" ir "false" yra anglų žodžiai, o ne Ruby raktiniai žodžiai, naudokite įprastą šriftą:

# Paleidžia visas patikras nurodytoje kontekste.
# Grąžina true, jei klaidų nerasta, false kitu atveju.
#
# Jei argumentas yra false (numatytasis yra +nil+), kontekstas yra
# nustatomas į <tt>:create</tt>, jei <tt>new_record?</tt> yra true,
# ir į <tt>:update</tt>, jei nėra.
#
# Patikros be <tt>:on</tt> parinkties bus vykdomos
# nepriklausomai nuo konteksto. Patikros su # kai kuriais <tt>:on</tt>
# parinktimis bus vykdomos tik nurodytame kontekste.
def valid?(context = nil)
  # ...
end

10 Aprašymo sąrašai

Sąrašuose su pasirinkimais, parametrais ir kt. tarp elemento ir jo aprašymo naudokite brūkšnį (geriau skaitosi nei dvitaškis, nes paprastai pasirinkimai yra simboliai):

# * <tt>:allow_nil</tt> - Praleisti patikrinimą, jei atributas yra +nil+.

Aprašymas prasideda didžiąja raide ir baigiasi tašku - tai standartinė anglų kalba.

Alternatyvus požiūris, kai norite pateikti papildomų detalės ir pavyzdžių, yra naudoti parinkčių skyriaus stilių.

ActiveSupport::MessageEncryptor#encrypt_and_sign yra puikus šio pavyzdžio pavyzdys.

# ==== Parinktys
#
# [+:expires_at+]
#   Laikas, kada žinutė pasibaigs. Po šio laiko žinutės patikrinimas
#   nepavyks.
#
#     message = encryptor.encrypt_and_sign("hello", expires_at: Time.now.tomorrow)
#     encryptor.decrypt_and_verify(message) # => "hello"
#     # Po 24 valandų...
#     encryptor.decrypt_and_verify(message) # => nil

11 Dinamiškai generuojami metodai

Metodai, sukurti naudojant (module|class)_eval(STRING), turi komentarą šalia su sugeneruoto kodo pavyzdžiu. Šis komentaras yra 2 tarpai nuo šablono:

(module|class)_eval(STRING) kodo komentarai

Jei rezultatas yra per platus, pvz., 200 stulpelių ar daugiau, komentarą padėkite virš kvietimo:

# def self.find_by_login_and_activated(*args)
#   options = args.extract_options!
#   ...
# end
self.class_eval %{
  def self.#{method_id}(*args)
    options = args.extract_options!
    ...
  end
}, __FILE__, __LINE__

12 Metodo matomumas

Rašant dokumentaciją Rails, svarbu suprasti skirtumą tarp viešo naudotojo sąsajos ir vidinės sąsajos.

Rails, kaip ir dauguma bibliotekų, naudoja privataus raktažodį iš Ruby vidinei sąsajai apibrėžti. Tačiau viešoji sąsaja laikosi šiek tiek kitokio konvencijos. Vietoj to, kad būtų priimta, jog visi vieši metodai skirti naudotojui, Rails naudoja :nodoc: direktyvą, kad pažymėtų šios rūšies metodus kaip vidinę sąsają.

Tai reiškia, kad yra metodų Rails su public matomumu, kurie nėra skirti naudotojui.

Pavyzdys to yra ActiveRecord::Core::ClassMethods#arel_table:

module ActiveRecord::Core::ClassMethods
  def arel_table # :nodoc:
    # padaryti kažką magiško..
  end
end

Jei pagalvojote, "šis metodas atrodo kaip viešas klasės metodas ActiveRecord::Core", buvote teisus. Tačiau iš tikrųjų Rails komanda nenori, kad naudotojai pasitikėtų šiuo metodu. Todėl jie pažymi jį kaip :nodoc: ir jis pašalinamas iš viešos dokumentacijos. Tokio sprendimo priežastis yra leisti komandai keisti šiuos metodus pagal jų vidines poreikius per išleidimus, kaip jie mano tinkamus. Šio metodo pavadinimas gali pasikeisti, arba grąžinimo reikšmė, arba visa klasė gali išnykti; nėra jokios garantijos, todėl neturėtumėte priklausyti nuo šios sąsajos savo įskiepiuose ar programose. Kitu atveju rizikuojate, kad jūsų programa ar juvelyras suges, kai atnaujinsite naujesnę Rails versiją.

Kaip bendradarbis, svarbu pagalvoti, ar ši sąsaja skirta galutiniam naudotojui. Rails komanda įsipareigoja nepakeisti viešos sąsajos per išleidimus be pilno pasenusio ciklo. Rekomenduojama :nodoc: pažymėti bet kurį vidinį jūsų metodą/klasę, nebent jie jau yra privačios (tai reiškia matomumą), tuomet jie pagal nutylėjimą yra vidinės. Kai sąsaja stabilizuojasi, matomumas gali pasikeisti, tačiau viešos sąsajos keitimas yra daug sunkesnis dėl suderinamumo atgal.

Klasė ar modulis pažymimas :nodoc:, kad būtų nurodyta, jog visi metodai yra vidinė sąsaja ir jais neturėtų būti naudojamasi tiesiogiai.

Apibendrinant, Rails komanda naudoja :nodoc:, kad pažymėtų viešai matomus metodus ir klases kaip vidinę sąsają; API matomumo pakeitimai turėtų būti apgalvoti ir aptarti per pull request'ą.

13 Dėl Rails steko

Dokumentuojant dalis iš Rails API, svarbu prisiminti visas dalis, kurios sudaro Rails steką.

Tai reiškia, kad elgsena gali keistis priklausomai nuo metodo ar klasės konteksto ar srities, kurią bandote dokumentuoti.

Skirtingose vietose yra skirtinga elgsena, kai atsižvelgiame į visą steką, vienas tokių pavyzdžių yra ActionView::Helpers::AssetTagHelper#image_tag:

# image_tag("icon.png")
#   # => <img src="/assets/icon.png" />

Nors numatytoji #image_tag elgsena visada yra grąžinti /images/icon.png, atsižvelgiant į visą Rails steką (įskaitant turinio rinkinį), galime matyti aukščiau pateiktą rezultatą.

Mums rūpi tik elgsena, patiriama naudojant visą numatytąjį Rails steką.

Šiuo atveju norime dokumentuoti framework'o elgseną, o ne tik šį konkretų metodą.

Jei turite klausimų, kaip Rails komanda tvarko tam tikrą API, nebijokite atidaryti užklausos arba siųsti pataisymą į problemos sekimo sistemą.

Atsiliepimai

Jūs esate skatinami padėti pagerinti šio vadovo kokybę.

Prašome prisidėti, jei pastebite rašybos klaidų ar faktinių klaidų. Norėdami pradėti, galite perskaityti mūsų dokumentacijos prisidėjimo skyrių.

Taip pat gali būti nepilnos informacijos arba informacijos, kuri nėra atnaujinta. Prašome pridėti bet kokią trūkstamą dokumentaciją pagrindiniam. Patikrinkite Edge vadovus pirmiausia, ar problemas jau išspręsta arba ne pagrindinėje šakoje. Patikrinkite Ruby on Rails vadovų gaires dėl stiliaus ir konvencijų.

Jei dėl kokios nors priežasties pastebite kažką, ką reikia ištaisyti, bet negalite patys tai pataisyti, prašome pranešti apie problemą.

Ir galiausiai, bet ne mažiau svarbu, bet koks diskusijos dėl Ruby on Rails dokumentacijos yra labai laukiamos oficialiame Ruby on Rails forume.