How can I comment multiple lines in Ruby?
-
8It's rather unfortunate that multiline comments in ruby look very much like a block of code. And given the high points awarded to this question (and the accepted answer) the people working on the ruby syntax should clearly think a bit about it. – Nick Jul 25 '15 at 19:30
10 Answers
#!/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.
- This is how it looks (via screenshot) - otherwise it's hard to interpret how the above comments will look. Click to Zoom-in:

- 16,305
- 23
- 120
- 273

- 25,687
- 2
- 57
- 59
-
31I really prefer using `#` over them all, mostly because it visually separates the commented lines better than `=begin`/`=end` or using the here-to method. And, nice job. – the Tin Man Dec 03 '10 at 04:44
-
1For me, in Ruby 1.9.3p194, using the heredoc style as shown above gives as `warning: possibly useless use of a literal in void context`. – David J. Jun 22 '12 at 17:42
-
39It's interesting that this answer makes some flaws in the syntax highlighter obvious. – ZoFreX Nov 16 '12 at 19:59
-
76Don't forget that `=begin` and `=end` cannot be preceded by any whitespace. – bergie3000 Feb 09 '13 at 00:02
-
17
-
If you're reading Ruby code in an editor that highlights rdoc comments correctly, they stand out, and your comments are less cluttered with a "#" starting every line. What's not to like? OTOH, a scan through the std library shows two hits, and a small smattering amongst my gems. OTOH, almost all Perl code uses POD. Maybe because the tools for generating HTML and man pages from Perl POD comments are so much further along than Ruby's. – Eric Jan 18 '14 at 02:23
-
1I would prefer to use #, but most of the time I use =begin ... =end because I'm too lazy to type all those # or learn how to do block comments in vim – May 06 '14 at 16:05
-
9It's important to note that in the above example code, only the first `=begin...=end` and last block using `#` are picked up by rdoc when generating documentation. – the Tin Man Aug 05 '14 at 19:50
-
the Heredoc format `<<-DOC` will interpolate so you can't use `#{}` variables inside easily. and if you try to use `<<-'DOC'` (which basically tells heredoc not to perform interpolation), it will most likely screw your syntax highlighting. – Cyril Duchon-Doris Sep 13 '18 at 13:24
-
`<<-DOC` will also create a String instance. So best to stick to `#` or `=begin`. – Cœur May 16 '19 at 12:22
-
1@AlbertCatalà: *And It is not possible to use =begin =end within a method* I tested, and it seems to work within a method. However, you can't indent it. What did you have in mind when you said "not possible?" Do you mean that it doesn't work with rdoc or something? – Jul 15 '21 at 15:38
-
@BenCrowell that is correct AlbertCatala is wrong. begin end block comments can be used _anywhere_. the _only_ restriction is that they cannot contain _any_ superceding whitespace on `=begin` or `=end` so they are very ugly unless at the root of a file – Sampson Crowley Dec 08 '21 at 18:38
=begin
My
multiline
comment
here
=end

- 38,111
- 12
- 81
- 101
-
4Sure, you *could* do this. It works. This is incredibly rare. I find it ugly. Maybe I'm stuck in my ways? – David J. Jun 22 '12 at 17:22
-
57I've found that if I include a tab before =begin or =end, the comments don't work. The =begin and =end each need to be written at the beginning of each line. – Rose Perrone Jun 22 '12 at 20:51
-
1you're not alone @DavidJames. I've personally opted to have them all commented out by my editor. CMD+/ or ALT+/ is the convention for most. – fIwJlxSzApHEZIl Oct 31 '16 at 23:06
-
1@DavidJames, what would you do instead? Type a `#` and space before every single line? It's a lot of keystrokes especially if I start adding line breaks. – Paul Draper Nov 15 '16 at 16:34
Despite the existence of =begin
and =end
, the normal and a more correct way to comment is to use #
's on each line. If you read the source of any ruby library, you will see that this is the way multi-line comments are done in almost all cases.

- 165,429
- 45
- 277
- 381

- 15,437
- 1
- 45
- 55
-
5You might get arguments about the "more correct" part of your statement as they're both valid. I prefer using `#` because it's more obvious. When commenting out code it's important to make it obvious that's what happened. If you're viewing the code without the benefit of code coloring in an editor using `=begin/=end` can make it tough to figure out why code is being ignored. – the Tin Man Dec 03 '10 at 04:48
-
6Sure, there are many "valid" ways to write comments. Let's be practical here. If you actually write Ruby and read what others write, you should be using `#` comments. (I am mystified why this had two downvotes. I guess the Stack Overflow community has to get it wrong sometimes!) – David J. Jun 22 '12 at 17:17
-
4`3 == three` where `def three; 1 + 1 + 1 end`. Therefore both are valid. Who cares? Use `3`! – David J. Jun 22 '12 at 17:19
-
1@theTinMan While true, generally the only time you'd lack syntax highlighting (in my experience) is when you're using `vi` on a production server. In which case, you probably shouldn't be doing your development there, anyway. – Parthian Shot Aug 05 '14 at 19:10
-
1@DavidJames Your example is ridiculous because it's more verbose. Putting a hash on every line is more verbose for longer comments. And if anyone thinks the phrase "/dev/urandom was used here for the nonblocking cryptographically-sound PRNG. Do not touch this code- it is magic" is my attempt at writing ruby, I would contend their confusion arises more from ignorance on their part than lack of clarity on mine. Which isn't to say your point is always invalid- it's just only a good one when commenting out code. But if your comment is just... comment... it should be clear either way. – Parthian Shot Aug 05 '14 at 19:13
-
@ParthianShot, even on my production hosts I have my standard ~/.vim defined. And some of my production hosts *are* for development by the users. – the Tin Man Aug 05 '14 at 19:44
-
@theTinMan I am experiencing a mixture of confused, hungry and tired. One of those emotions is a response to your comment. The default highlighting in vim usually works well. When don't you have highlighting? **EDIT:** It was confused. Took me a bit but I got it sussed. – Parthian Shot Aug 05 '14 at 19:58
-
You don't get default highlighting with a stripped vim on a ssh session with a terminal mismatch, or where vim doesn't understand the file type, especially on our hosts which are way out of date. My first task on any machine I help manage is to update vim from source to the latest full version just because I can't stand stripped vim but some machines I use I don't manage. – the Tin Man Aug 05 '14 at 21:08
-
1
#!/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!"

- 181,842
- 47
- 306
- 310
-
1+1 because I had no idea nesting was a thing in Ruby multiline comments. – Parthian Shot Aug 05 '14 at 19:17
-
4@ParthianShot - It is not a thing - =begin and =end are ignored if not at the beginning of a line. Nesting does not seem to be possible. – skagedal Feb 24 '15 at 21:05
-
Nesting a comment inside a comment would result in either a single comment or a syntax error from trying to end a comment where there is no comment to end. `/*I am a\n#nested\ncomment, which really serves no purpose*/` `/*I am bound /*to*/ FAIL!*/` It could make sense if you have single line comments and code inside of a multiline comment, such as a function with documentation that you don't want people to use, but you also don't want to remove it from the file. – Chinoto Vokro Jul 24 '16 at 21:57
Using either:
=begin This is a comment block =end
or
# This # is # a # comment # block
are the only two currently supported by rdoc, which is a good reason to use only these I think.

- 158,662
- 42
- 215
- 303
-
1Another good reason to stick to `=begin` or `#` is that both `<<-DOC` and `"` syntaxes will generate useless string literals at execution. – Cœur May 16 '19 at 12:27
=begin
comment line 1
comment line 2
=end
make sure =begin
and =end
is the first thing on that line (no spaces)

- 40,884
- 11
- 78
- 89

- 5,817
- 4
- 34
- 33
Here is an example :
=begin
print "Give me a number:"
number = gets.chomp.to_f
total = number * 10
puts "The total value is : #{total}"
=end
Everything you place in between =begin
and =end
will be treated as a comment regardless of how many lines of code it contains between.
Note: Make sure there is no space between =
and begin
:
- Correct:
=begin
- Wrong:
= begin
=begin
(some code here)
=end
and
# This code
# on multiple lines
# is commented out
are both correct. The advantage of the first type of comment is editability—it's easier to uncomment because fewer characters are deleted. The advantage of the second type of comment is readability—reading the code line by line, it's much easier to tell that a particular line has been commented out. Your call but think about who's coming after you and how easy it is for them to read and maintain.

- 5,627
- 11
- 36
- 64
-
IMO, `=begin` and `=end` do not visually convey that what is in-between is a comment... Clojure, for example, uses `(comment :whatever)` which at leads says what it means: http://stackoverflow.com/questions/1191628/block-comments-in-clojure – David J. Aug 06 '14 at 03:36
-
1Neither do "/*" and "*/" in Java, C and C++. As with the Ruby syntax, large blocks of code might be commented out between those two characters, and everyone who knows the basics of the language knows what they mean. – La-comadreja Aug 06 '14 at 14:11
-
1Syntax coloring (in vim, for example) shows that the first type is a comment. In that case, the first type has no disadvantages. – Camille Goudeseune Apr 12 '17 at 20:41
In case someone is looking for a way to comment multiple lines in a html template in Ruby on Rails, there might be a problem with =begin =end, for instance:
<%
=begin
%>
... multiple HTML lines to comment out
<%= image_tag("image.jpg") %>
<%
=end
%>
will fail because of the %> closing the image_tag.
In this case, maybe it is arguable whether this is commenting out or not, but I prefer to enclose the undesired section with an "if false" block:
<% if false %>
... multiple HTML lines to comment out
<%= image_tag("image.jpg") %>
<% end %>
This will work.

- 682
- 1
- 8
- 17
-
1The multi line comment with begin and end, like your first code snippet, actually works. – Robert Sep 28 '20 at 09:52
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
Note that at the moment of the post, the stackoverflow engine doesn't render syntax coloration correctly. Testing how it renders in your editor of choice is let as an exercise. ;)

- 2,783
- 3
- 27
- 44