Mehrzeilige Kommentare in Ruby?


746

Wie kann ich mehrere Zeilen in Ruby kommentieren?


7
Falls jemand auf der Suche nach mehrzeiligen Kommentaren in Puppet- .ppManifesten (die auf einer Ruby-ähnlichen Syntax basieren) darauf /**/
stößt,

6
Es ist ziemlich bedauerlich, dass mehrzeilige Kommentare in Ruby einem Codeblock sehr ähnlich sehen. Und angesichts der Höhepunkte dieser Frage (und der akzeptierten Antwort) sollten die Leute, die an der Ruby-Syntax arbeiten, ein wenig darüber nachdenken.
Nick

Antworten:


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.
  • So sieht es aus (per Screenshot) - ansonsten ist es schwer zu interpretieren, wie die obigen Kommentare aussehen werden. Zum Vergrößern klicken :

Kommentare in einem Texteditor


26
Ich bevorzuge es wirklich, #sie alle zu verwenden, hauptsächlich, weil sie die kommentierten Zeilen visuell besser trennen als =begin/ =endoder die Here-to-Methode verwenden. Und gute Arbeit.
der Blechmann

38
Es ist interessant, dass diese Antwort einige Fehler im Syntax-Textmarker offensichtlich macht.
ZoFreX

69
Vergessen Sie das nicht =beginund es =enddarf kein Leerzeichen vorangestellt werden.
bergie3000

15
Und es ist nicht möglich, = begin = end innerhalb einer Methode zu verwenden
Albert Català

7
Es ist wichtig zu beachten, dass im obigen Beispielcode beim Generieren der Dokumentation nur der erste =begin...=endund der letzte verwendete Block #von rdoc erfasst werden.
der Blechmann

126
=begin
My 
multiline
comment
here
=end

4
Sicher, Sie könnten dies tun. Es klappt. Das ist unglaublich selten. Ich finde es hässlich. Vielleicht stecke ich in meinen Wegen fest?
David J.

53
Ich habe festgestellt, dass die Kommentare nicht funktionieren, wenn ich vor = begin oder = end einen Tab einfüge. Das = Anfang und = Ende muss jeweils am Anfang jeder Zeile geschrieben werden.
Rose Perrone

1
du bist nicht allein @DavidJames. Ich persönlich habe mich dafür entschieden, sie alle von meinem Redakteur auskommentieren zu lassen. CMD + / oder ALT + / ist die Konvention für die meisten.
anon58192932

1
@ DavidJames, was würdest du stattdessen tun? Geben Sie #vor jeder einzelnen Zeile ein Leerzeichen ein? Es sind viele Tastenanschläge, besonders wenn ich anfange, Zeilenumbrüche hinzuzufügen.
Paul Draper

57

Trotz der Existenz von =beginund =endist die normale und korrektere Art zu kommentieren #, in jeder Zeile 's zu verwenden. Wenn Sie die Quelle einer Ruby-Bibliothek lesen, werden Sie feststellen, dass in fast allen Fällen mehrzeilige Kommentare auf diese Weise erstellt werden.


4
Möglicherweise erhalten Sie Argumente zum "korrekteren" Teil Ihrer Aussage, da beide gültig sind. Ich benutze #es lieber, weil es offensichtlicher ist. Beim Auskommentieren von Code ist es wichtig, deutlich zu machen, dass genau das passiert ist. Wenn Sie den Code ohne die Vorteile der Codefärbung in einem Editor anzeigen, =begin/=endkann es schwierig sein, herauszufinden, warum Code ignoriert wird.
der Blechmann

6
Sicher, es gibt viele "gültige" Möglichkeiten, Kommentare zu schreiben. Lassen Sie uns hier praktisch sein. Wenn Sie tatsächlich Ruby schreiben und lesen, was andere schreiben, sollten Sie #Kommentare verwenden. (Ich bin verwirrt, warum dies zwei Abstimmungen hatte. Ich denke, die Stack Overflow-Community muss es manchmal falsch machen!)
David J.

4
3 == threewo def three; 1 + 1 + 1 end. Daher sind beide gültig. Wen interessiert das? Verwenden Sie 3!
David J.

1
@theTinMan Obwohl dies der Fall ist, fehlt (meiner Erfahrung nach) die Syntaxhervorhebung im Allgemeinen nur, wenn Sie sie viauf einem Produktionsserver verwenden. In diesem Fall sollten Sie Ihre Entwicklung dort wahrscheinlich sowieso nicht durchführen.
Parthian Shot

1
@ DavidJames Dein Beispiel ist lächerlich, weil es ausführlicher ist. Das Einfügen eines Hashs in jede Zeile ist für längere Kommentare ausführlicher. Und wenn jemand denkt, dass der Ausdruck "/ dev / urandom hier für das nicht blockierende kryptografisch klingende PRNG verwendet wurde. Berühren Sie diesen Code nicht - es ist magisch" mein Versuch ist, Rubin zu schreiben, würde ich behaupten, dass ihre Verwirrung eher aus Unwissenheit über sie resultiert Teil als mangelnde Klarheit auf meine. Das heißt nicht, dass Ihr Punkt immer ungültig ist - er ist nur ein guter Punkt, wenn Sie Code auskommentieren. Aber wenn Ihr Kommentar nur ... Kommentar ... ist, sollte es so oder so klar sein.
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, weil ich keine Ahnung hatte, dass das Verschachteln eine Sache in mehrzeiligen Ruby-Kommentaren war.
Parthian Shot

2
@ParthianShot - Es ist keine Sache - = Anfang und = Ende werden ignoriert, wenn nicht am Anfang einer Zeile. Verschachtelung scheint nicht möglich zu sein.
Skagedal

Das Verschachteln eines Kommentars in einem Kommentar würde entweder zu einem einzelnen Kommentar oder zu einem Syntaxfehler führen, wenn versucht wird, einen Kommentar zu beenden, wenn kein zu beendender Kommentar vorhanden ist. /*I am a\n#nested\ncomment, which really serves no purpose*/ /*I am bound /*to*/ FAIL!*/Es kann sinnvoll sein, wenn Sie mehrzeilige Kommentare und Code in einem mehrzeiligen Kommentar haben, z. B. eine Funktion mit Dokumentation, die nicht von Personen verwendet werden soll, die Sie jedoch auch nicht aus der Datei entfernen möchten.
Chinoto Vokro

17

Verwenden Sie entweder:

= beginne
Diese
ist
ein
Kommentar
Block
= Ende

oder

# Diese
# ist
# ein
# Kommentar
# Block

sind die einzigen zwei, die derzeit von rdoc unterstützt werden, was meiner Meinung nach ein guter Grund ist, nur diese zu verwenden.


1
Ein weiterer guter Grund, sich an =beginoder zu halten, #ist, dass beide <<-DOCund die "Syntax bei der Ausführung nutzlose Zeichenfolgenliterale erzeugen.
Cœur

13
=begin
(some code here)
=end

und

# This code
# on multiple lines
# is commented out

sind beide richtig. Der Vorteil des ersten Kommentartyps ist die Bearbeitbarkeit. Das Kommentieren ist einfacher, da weniger Zeichen gelöscht werden. Der Vorteil des zweiten Kommentartyps ist die Lesbarkeit: Wenn Sie den Code zeilenweise lesen, ist es viel einfacher zu erkennen, dass eine bestimmte Zeile auskommentiert wurde. Ihr Anruf, aber denken Sie darüber nach, wer nach Ihnen kommt und wie einfach es für sie ist, zu lesen und zu pflegen.


IMO, =beginund =endvermitteln Sie nicht visuell, dass das, was dazwischen liegt, ein Kommentar ist ... Clojure verwendet zum Beispiel, (comment :whatever)was bei Leads sagt, was es bedeutet: stackoverflow.com/questions/1191628/block-comments-in-clojure
David J.

1
"/ *" Und "* /" in Java, C und C ++ auch nicht. Wie bei der Ruby-Syntax können große Codeblöcke zwischen diesen beiden Zeichen auskommentiert werden, und jeder, der die Grundlagen der Sprache kennt, weiß, was sie bedeuten.
La-Comadreja

1
Die Syntaxfärbung (z. B. in vim) zeigt, dass der erste Typ ein Kommentar ist. In diesem Fall hat der erste Typ keine Nachteile.
Camille Goudeseune

12

Hier ist ein Beispiel :

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

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

=end

Alles , was Sie legen dazwischen =beginund =endwird als Kommentar behandelt werden , unabhängig davon , wie viele Zeilen Code enthält zwischen.

Hinweis: Stellen Sie sicher, dass zwischen =und kein Leerzeichen steht begin:

  • Richtig: =begin
  • Falsch: = begin

5

=begin comment line 1 comment line 2 =end Stellen Sie sicher, dass = Anfang und = Ende das erste in dieser Zeile ist (keine Leerzeichen).


2

Wenn jemand nach einer Möglichkeit sucht, mehrere Zeilen in einer HTML-Vorlage in Ruby on Rails zu kommentieren, liegt möglicherweise ein Problem mit = begin = end vor, zum Beispiel:

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

schlägt fehl, weil%> das image_tag schließt.

In diesem Fall ist es vielleicht fraglich, ob dies auskommentiert wird oder nicht, aber ich ziehe es vor, den unerwünschten Abschnitt mit einem "if false" -Block zu versehen:

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

Das wird funktionieren.


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

Beachten Sie, dass die Stackoverflow-Engine zum Zeitpunkt des Beitrags die Syntaxfärbung nicht korrekt wiedergibt. Das Testen, wie es in einem Editor Ihrer Wahl gerendert wird, wird als Übung zugelassen. ;)

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.