Komentarze wieloliniowe w Rubim?


746

Jak mogę komentować wiele linii w Ruby?


7
Na wypadek, gdyby ktokolwiek wpadł na to, szukając wieloliniowych komentarzy w .ppmanifestach Puppet (opartych na składni podobnej do Ruby) , możesz użyć komentarzy blokowych w stylu c /**/
msanford

6
Szkoda, że ​​wieloliniowe komentarze w rubinie wyglądają bardzo podobnie do bloku kodu. Biorąc pod uwagę wysokie punkty przyznane temu pytaniu (i przyjętej odpowiedzi), ludzie pracujący nad składnią ruby ​​powinni wyraźnie się nad tym zastanowić.
Nick

Odpowiedzi:


1354
#!/usr/bin/env ruby

=begin
Every body mentioned this way
to have multiline comments.

The =begin and =end must be at the beginning of the line or
it will be a syntax error.
=end

puts "Hello world!"

<<-DOC
Also, you could create a docstring.
which...
DOC

puts "Hello world!"

"..is kinda ugly and creates
a String instance, but I know one guy
with a Smalltalk background, who
does this."

puts "Hello world!"

##
# most
# people
# do
# this


__END__

But all forgot there is another option.
Only at the end of a file, of course.
  • Tak to wygląda (poprzez zrzut ekranu) - w przeciwnym razie trudno będzie zinterpretować, jak będą wyglądały powyższe komentarze. Kliknij, aby powiększyć :

Komentarze w edytorze tekstu


26
Naprawdę wolę używać #nad nimi wszystkimi, głównie dlatego, że wizualnie oddziela skomentowane linie lepiej niż =begin/ =endlub stosując metodę tu-to. I niezła robota.
Tin Man,

38
Interesujące jest to, że ta odpowiedź uwidacznia pewne wady w zakreślaczu składni.
ZoFreX

69
Nie zapominaj o tym =begini =endnie może być poprzedzony żadnymi spacjami.
bergie3000

15
I nie można użyć = start = koniec w ramach metody
Albert Català,

7
Należy zauważyć, że w powyższym przykładowym kodzie rdoc pobiera tylko pierwszy =begin...=endi ostatni #użyty blok podczas generowania dokumentacji.
Tin Man

126
=begin
My 
multiline
comment
here
=end

4
Jasne, możesz to zrobić. To działa. To jest niezwykle rzadkie. Uważam to za brzydkie. Może utknąłem na moich drogach?
David J.

53
Przekonałem się, że jeśli dołączę kartę przed = początek lub = koniec, komentarze nie działają. = = Początek i = koniec należy zapisać na początku każdego wiersza.
Rose Perrone

1
nie jesteś sam @DavidJames. Osobiście zdecydowałem, że wszystkie zostaną skomentowane przez mojego redaktora. CMD + / lub ALT + / to konwencja dla większości.
anon58192932,

1
@DavidJames, co byś zrobił zamiast tego? Wpisz a #i spację przed każdą linią? To dużo naciśnięć klawiszy, zwłaszcza jeśli zaczynam dodawać podział wiersza.
Paul Draper,

57

Pomimo istnienia =begini =end, normalnym i bardziej poprawnym sposobem komentowania jest użycie #w każdym wierszu. Jeśli przeczytasz źródło dowolnej biblioteki ruby, zobaczysz, że w ten sposób komentarze we wszystkich wierszach są wykonywane prawie we wszystkich przypadkach.


4
Możesz otrzymać argumenty dotyczące „bardziej poprawnej” części twojego oświadczenia, ponieważ oba są prawidłowe. Wolę używać, #ponieważ jest to bardziej oczywiste. Podczas komentowania kodu ważne jest, aby było oczywiste, że tak właśnie się stało. Jeśli przeglądasz kod bez korzyści z kolorowania kodu w edytorze, użycie =begin/=endmoże utrudnić ustalenie , dlaczego kod jest ignorowany.
Tin Man,

6
Oczywiście istnieje wiele „prawidłowych” sposobów pisania komentarzy. Bądźmy tu praktyczni. Jeśli faktycznie piszesz Ruby i czytasz to, co piszą inni, powinieneś używać #komentarzy. (Zastanawiam się, dlaczego miało to dwa negatywne zdanie. Wydaje mi się, że społeczność Stack Overflow czasami się myli!)
David J.,

4
3 == threegdzie def three; 1 + 1 + 1 end. Dlatego oba są ważne. Kogo to obchodzi? Użyj 3!
David J.

1
@ theTinMan Chociaż jest to prawda, ogólnie rzecz biorąc, jedyne, w którym brakuje ci podświetlania składni (z mojego doświadczenia), kiedy używasz vina serwerze produkcyjnym. W takim razie i tak prawdopodobnie nie powinieneś się tam rozwijać.
Parthian Shot

1
@DavidJames Twój przykład jest śmieszny, ponieważ jest bardziej szczegółowy. Umieszczanie skrótu w każdej linii jest bardziej szczegółowe dla dłuższych komentarzy. I jeśli ktoś myśli, że użyto tutaj wyrażenia „/ dev / urandom do nieblokującego kryptograficznie dźwiękowego PRNG. Nie dotykaj tego kodu - to magia” - to moja próba napisania rubinu, twierdziłbym, że ich zamieszanie wynika bardziej z niewiedzy na ich temat część niż brak jasności na mojej. Co nie znaczy, że twój punkt jest zawsze nieważny - jest tylko dobry podczas komentowania kodu. Ale jeśli twój komentarz jest po prostu ... komentarz ... powinien być jasny.
Parthian Shot

20
#!/usr/bin/env ruby

=begin
Between =begin and =end, any number
of lines may be written. All of these
lines are ignored by the Ruby interpreter.
=end

puts "Hello world!"

1
+1, ponieważ nie miałem pojęcia, że ​​zagnieżdżanie jest rzeczą w komentarzach rubinowych.
Parthian Shot

2
@ParthianShot - To nie jest rzecz - = początek i = koniec są ignorowane, jeśli nie na początku linii. Zagnieżdżanie wydaje się niemożliwe.
skagedal

Zagnieżdżenie komentarza wewnątrz komentarza spowodowałoby pojedynczy komentarz lub błąd składniowy przy próbie zakończenia komentarza, gdy nie ma komentarza do końca. /*I am a\n#nested\ncomment, which really serves no purpose*/ /*I am bound /*to*/ FAIL!*/Może to mieć sens, jeśli w komentarzu wielowierszowym znajdują się komentarze jednowierszowe i kod, takie jak funkcja z dokumentacją, której nie chcesz, aby ludzie korzystali, ale nie chcesz również usuwać jej z pliku.
Chinoto Vokro

17

Używając albo:

= początek
To
jest
za
komentarz
blok
= koniec

lub

# To
# jest
# a
# komentarz
# blok

są jedynymi dwoma obecnie obsługiwanymi przez rdoc, co jest dobrym powodem, aby używać tylko tych, jak sądzę.


1
Innym dobrym powodem do trzymania się =beginlub #jest to, że obie <<-DOCi "składnie generują bezużyteczne literały łańcuchowe podczas wykonywania.
Cœur

13
=begin
(some code here)
=end

i

# This code
# on multiple lines
# is commented out

oba są poprawne. Zaletą pierwszego typu komentarza jest możliwość edytowania - łatwiej jest odkomentować, ponieważ usuwa się mniej znaków. Zaletą drugiego rodzaju komentarza jest czytelność - czytając kod wiersz po wierszu, znacznie łatwiej jest stwierdzić, że dany wiersz został skomentowany. Zadzwoń, ale zastanów się, kto będzie za tobą i jak łatwo jest je czytać i utrzymywać.


IMO =begini =endnie przekazuj wizualnie, że to, co jest pomiędzy, jest komentarzem. Na przykład Clojure używa, (comment :whatever)co na leadach mówi, co to znaczy: stackoverflow.com/questions/1191628/block-comments-in-clojure
David J.

1
Nie używaj także „/ *” i „* /” w Javie, C i C ++. Podobnie jak w przypadku składni Ruby, między tymi dwoma znakami można komentować duże bloki kodu, a każdy, kto zna podstawy języka, wie, co one oznaczają.
La-comadreja

1
Kolorowanie składni (na przykład w vimie) pokazuje, że pierwszy typ to komentarz. W takim przypadku pierwszy typ nie ma wad.
Camille Goudeseune,

12

Oto przykład :

=begin 
print "Give me a number:"
number = gets.chomp.to_f

total = number * 10
puts  "The total value is : #{total}"

=end

Wszystko, co umieścisz pomiędzy =begini =endbędzie traktowane jako komentarz bez względu na to, ile wierszy kodu zawiera pomiędzy.

Uwaga: Upewnij się, że nie ma spacji między =i begin:

  • Poprawny: =begin
  • Źle: = begin

4

=begin comment line 1 comment line 2 =end upewnij się, że = początek i = koniec to pierwsza rzecz w tym wierszu (bez spacji)


2

Jeśli ktoś szuka sposobu na komentowanie wielu linii w szablonie HTML w Ruby on Rails, może wystąpić problem z = start = koniec, na przykład:

<%
=begin
%>
  ... multiple HTML lines to comment out
  <%= image_tag("image.jpg") %>
<%
=end
%>

zakończy się niepowodzeniem z powodu%> zamknięcia tagu obrazu.

W tym przypadku może być dyskusyjne, czy to komentuje, czy nie, ale wolę dołączyć niepożądaną sekcję blokiem „jeśli fałszywy”:

<% if false %>
  ... multiple HTML lines to comment out
  <%= image_tag("image.jpg") %>
<% end %>

To zadziała.


0
  def idle
    <<~aid
    This is some description of what idle does.

    It does nothing actually, it's just here to show an example of multiline
    documentation. Thus said, this is something that is more common in the
    python community. That's an important point as it's good to also fit the
    expectation of your community of work. Now, if you agree with your team to
    go with a solution like this one for documenting your own base code, that's
    fine: just discuss about it with them first.

    Depending on your editor configuration, it won't be colored like a comment,
    like those starting with a "#". But as any keyword can be used for wrapping
    an heredoc, it is easy to spot anyway. One could even come with separated
    words for different puposes, so selective extraction for different types of
    documentation generation would be more practical. Depending on your editor,
    you possibly could configure it to use the same syntax highlight used for
    monoline comment when the keyword is one like aid or whatever you like.

    Also note that the squiggly-heredoc, using "~", allow to position
    the closing term with a level of indentation. That avoids to break the visual reading flow, unlike this far too long line.
    aid
  end

Zauważ, że w momencie ogłoszenia silnik stackoverflow nie wyświetla poprawnie kolorowania składni. Testowanie, jak renderuje się w wybranym edytorze, jest ćwiczeniem. ;)

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.