Rubyの複数行コメント?


746

Rubyで複数行にコメントするにはどうすればよいですか?


7
Puppet .ppマニフェスト(Rubyのような構文に基づく)で複数行コメントを探している人がこれに該当する場合は、cスタイルのブロックコメントを使用できます /**/
msanford

6
ルビの複数行コメントがコードのブロックに非常によく似ているのは残念です。そして、この質問(および受け入れられた回答)に与えられた高いポイントを考えると、ルビ構文に取り組んでいる人々はそれについて明確に少し考えるべきです。
ニック

回答:


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.
  • これは(スクリーンショットを介して)外観です。そうでない場合、上記のコメントがどのように表示されるかを解釈するのは困難です。クリックして拡大

テキストエディター内のコメント


26
私は#それらすべてを使用することを本当に好みます、それは主にそれが=begin/ よりもコメントされた行を視覚的に分離するため、=endまたはhere-toメソッドを使用するためです。そして、いい仕事。
Tin Man、

38
この回答が構文ハイライターのいくつかの欠陥を明らかにするのは興味深いことです。
ZoFreX

69
ことを忘れてはいけない=begin=end空白が先行することはできません。
bergie3000 2013

15
また、メソッド内で= begin = endを使用することはできません
AlbertCatalàJan

7
上記のコード例では、ドキュメントの生成時にrdocが=begin...=end使用するの#は最初と最後のブロックのみであることに注意してください。
ティンマン

126
=begin
My 
multiline
comment
here
=end

4
もちろん、これ行うことができます。できます。これは非常にまれです。私はそれを醜く見つけます。多分私は自分のやり方で行き詰まっていますか?
David J.

53
= beginまたは= endの前にタブを含めると、コメントが機能しないことがわかりました。= beginと= endはそれぞれ、各行の先頭に記述する必要があります。
ローズペローネ2012年

1
@DavidJamesだけではありません。私は個人的に、編集者がそれらすべてをコメント化することを選択しました。CMD + /またはALT + /は、ほとんどの場合の規則です。
anon58192932

1
@DavidJames、代わりに何をしますか?#各行の前にスペースを入力しますか?特に改行を追加し始めると、多くのキーストロークになります。
Paul Draper

57

=beginおよびの存在にもかかわらず、=endコメントを付ける通常のより正しい方法は#、各行でを使用することです。Rubyライブラリのソースを読むと、ほとんどの場合、これが複数行コメントの作成方法であることがわかります。


4
どちらも有効であるため、ステートメントの「より正しい」部分についての引数を取得する可能性があります。#わかりやすいので使用することを好みます。コードをコメントアウトするとき、それが起こったことを明確にすることが重要です。エディターでコードの色分けの利点なしにコードを表示している場合、を使用=begin/=endすると、コードが無視されている理由を理解するのが難しくなる可能性があります。
Tin Man

6
確かに、コメントを書くには多くの「有効な」方法があります。ここで実用的にしましょう。実際にRubyを書いて他の人が書いたものを読む場合は、#コメントを使用する必要があります。(なぜこれが2つの反対票を投じたのか私は不思議に思います。StackOverflowコミュニティは時々それを誤解する必要があると思います!)
David J.

4
3 == threeどこdef three; 1 + 1 + 1 end。したがって、両方が有効です。誰も気にしない?使用してください3
デビッドJ.

1
@theTinMan trueですが、一般的に、(私の経験では)構文の強調表示が欠けているのは、運用viサーバーで使用しているときだけです。どちらにしても、おそらくそこで開発を行うべきではありません。
パルティアンショット

1
@DavidJamesあなたの例はもっと冗長なのでばかげています。すべての行にハッシュを付けると、コメントが長いほど冗長になります。そして、「/ dev / urandomが暗号化されていないノンブロッキングPRNGのためにここで使用されました。このコードに触れないでください-それは魔法です」というフレーズがルビを書く私の私の試みであると思う場合、私は彼らの無知からさらに混乱が生じていると主張します私の明快さの欠如よりも一部。これは、あなたの主張が常に無効であると言っているのではありません。コードをコメントアウトするとき、それは単なる良い説明です。しかし、あなたのコメントがちょうど...コメントである場合、それはどちらの方法でも明確でなければなりません。
パルティアンショット

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は、Rubyの複数行コメントにネストが含まれていることを知らなかったためです。
パルティアンショット

2
@ParthianShot-事ではありません-= beginと= endは、行の先頭でなければ無視されます。ネスティングは可能ではないようです。
skagedal 2015

コメント内にコメントをネストすると、終了するコメントがない場所でコメントを終了しようとすると、単一のコメントまたは構文エラーが発生します。/*I am a\n#nested\ncomment, which really serves no purpose*/ /*I am bound /*to*/ FAIL!*/1行のコメントと複数行のコメント内のコードがある場合、たとえば、ドキュメントに関数を使用させたくないが、ファイルから削除したくない場合は、理にかなっています。
Chinoto Vokro

17

いずれかを使用:

=開始
この
です
a
コメント
ブロック
=終了

または

# この
#は
#a
#コメント
#ブロック

現在rdocでサポートされているのは2つだけなので、これだけを使用するのがよいと思います。


1
固執するもう一つの良い理由=beginかは、#両方のことである<<-DOC"構文は、実行時に役に立たない文字列リテラルを生成します。
・クール

13
=begin
(some code here)
=end

そして

# This code
# on multiple lines
# is commented out

どちらも正しいです。最初のタイプのコメントの利点は編集可能性です。削除される文字が少ないため、コメントを外しやすくなります。2番目のタイプのコメントの利点は、読みやすさです。コードを1行ずつ読み取ると、特定の行がコメント化されていることを簡単に確認できます。あなたの電話ですが、あなたの後に来るのは誰か、そして彼らが読んで維持するのがどれほど簡単かについて考えてください。


IMOで=beginあり、=endその間にあるものがコメントであることを視覚的に伝えない...たとえば、Clojureは、(comment :whatever)リードでそれが何を意味するかを言うものを使用します:stackoverflow.com/questions/1191628/block-comments-in-clojure
David J.

1
Java、C、C ++では、「/ *」と「* /」はどちらも使用できません。Ruby構文の場合と同様に、これらの2つの文字の間でコードの大きなブロックがコメント化されている場合があり、言語の基本を知っている人は誰でもその意味を知っています。
La-comadreja 2014

1
構文の色分け(vimなど)は、最初のタイプがコメントであることを示しています。その場合、最初のタイプには欠点はありません。
Camille Goudeseune

12

次に例を示します。

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

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

=end

すべてはあなたが間に配置=beginし、=end関係なく、それが間に含まれているどのように多くのコードの行のコメントとして扱われます。

注:=との間にスペースがないことを確認してくださいbegin

  • 正しい: =begin
  • 違う: = begin

5

=begin comment line 1 comment line 2 =end = beginと= endがその行の最初のものであることを確認してください(スペースなし)


2

Ruby on Railsのhtmlテンプレートの複数の行にコメントする方法を探している場合、= begin = endに問題がある可能性があります。たとえば、次のようになります。

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

%>がimage_tagを閉じるため、失敗します。

この場合、おそらくこれがコメント化されているかどうかは議論の余地がありますが、私は不要なセクションを「if false」ブロックで囲むことを好みます:

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

これは機能します。


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

投稿の時点では、stackoverflowエンジンは構文の色付けを正しくレンダリングしないことに注意してください。選択したエディタでどのようにレンダリングされるかをテストすることは、演習として行います。;)

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.