Nhận xét nhiều dòng trong Ruby?


746

Làm cách nào tôi có thể nhận xét nhiều dòng trong Ruby?


7
Trong trường hợp bất cứ ai rơi vào trường hợp này đang tìm kiếm các bình luận đa dòng trong các .ppbản kê khai của Puppet (dựa trên cú pháp giống như Ruby), bạn có thể sử dụng các nhận xét khối kiểu c /**/
msanford

6
Thật không may là các bình luận đa dòng trong ruby ​​trông rất giống một khối mã. Và với những điểm cao được trao cho câu hỏi này (và câu trả lời được chấp nhận), những người làm việc theo cú pháp ruby ​​nên suy nghĩ rõ ràng một chút về nó.
Nick

Câu trả lời:


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.
  • Đây là giao diện của nó (thông qua ảnh chụp màn hình) - nếu không, thật khó để diễn giải các ý kiến ​​trên sẽ trông như thế nào. Bấm để phóng to :

Nhận xét trong một trình soạn thảo văn bản


26
Tôi thực sự thích sử dụng #hơn tất cả chúng, chủ yếu là vì nó phân tách trực quan các dòng nhận xét tốt hơn =begin/ =endhoặc sử dụng phương pháp tại đây. Và, công việc tốt.
Tin Man

38
Thật thú vị khi câu trả lời này làm cho một số sai sót trong cú pháp tô sáng rõ ràng.
ZoFreX

69
Đừng quên điều đó =begin=endkhông thể đi trước bởi bất kỳ khoảng trắng nào.
bergie3000

15
Và không thể sử dụng = started = end trong một phương thức
Albert Català

7
Điều quan trọng cần lưu ý là trong mã ví dụ trên, chỉ có khối đầu tiên =begin...=endvà khối cuối sử dụng #được chọn bởi ndoc khi tạo tài liệu.
Tin Man

126
=begin
My 
multiline
comment
here
=end

4
Chắc chắn, bạn có thể làm điều này. Nó hoạt động. Điều này là vô cùng hiếm. Tôi thấy nó xấu xí. Có lẽ tôi bị mắc kẹt trong cách của tôi?
David J.

53
Tôi đã thấy rằng nếu tôi bao gồm một tab trước = bắt đầu hoặc = kết thúc, các nhận xét sẽ không hoạt động. = Bắt đầu và = kết thúc mỗi cần phải được viết ở đầu mỗi dòng.
Hoa hồng Perrone

1
bạn không đơn độc @DavidJames. Cá nhân tôi đã chọn để tất cả họ nhận xét bởi biên tập viên của tôi. CMD + / hoặc ALT + / là quy ước cho hầu hết.
anon58192932

1
@DavidJames, bạn sẽ làm gì thay thế? Nhập a #và khoảng trắng trước mỗi dòng đơn? Đó là rất nhiều tổ hợp phím đặc biệt là nếu tôi bắt đầu thêm ngắt dòng.
Paul Draper

57

Bất chấp sự tồn tại của =begin=end, cách nhận xét bình thường và đúng đắn hơn là sử dụng #trên mỗi dòng. Nếu bạn đọc nguồn của bất kỳ thư viện ruby ​​nào, bạn sẽ thấy rằng đây là cách nhận xét nhiều dòng trong hầu hết các trường hợp.


4
Bạn có thể nhận được các đối số về phần "chính xác hơn" trong tuyên bố của mình vì cả hai đều hợp lệ. Tôi thích sử dụng #vì nó rõ ràng hơn. Khi bình luận mã, điều quan trọng là phải làm rõ điều đó là những gì đã xảy ra. Nếu bạn đang xem mã mà không có lợi ích của việc tô màu mã trong trình chỉnh sửa bằng cách sử dụng =begin/=endcó thể khiến bạn khó hiểu tại sao mã bị bỏ qua.
Tin Man

6
Chắc chắn, có nhiều cách "hợp lệ" để viết bình luận. Hãy thực tế ở đây. Nếu bạn thực sự viết Ruby và đọc những gì người khác viết, bạn nên sử dụng các #bình luận. (Tôi đang bối rối tại sao điều này có hai lần tải xuống. Tôi đoán cộng đồng Stack Overflow đôi khi phải hiểu sai!)
David J.

4
3 == threenơi def three; 1 + 1 + 1 end. Do đó cả hai đều hợp lệ. Ai quan tâm? Sử dụng 3!
David J.

1
@theTinMan Mặc dù đúng, nói chung, lần duy nhất bạn thiếu tô sáng cú pháp (theo kinh nghiệm của tôi) là khi bạn đang sử dụng vitrên máy chủ sản xuất. Trong trường hợp đó, dù sao đi nữa, có lẽ bạn không nên thực hiện sự phát triển của mình ở đó.
Bắn Parthian

1
@DavidJames Ví dụ của bạn thật lố bịch vì nó dài dòng hơn. Đặt một hàm băm trên mỗi dòng sẽ dài dòng hơn cho các bình luận dài hơn. Và nếu bất cứ ai nghĩ rằng cụm từ "/ dev / urandom đã được sử dụng ở đây cho PRNG âm thanh không mã hóa. Đừng chạm vào mã này - đó là phép thuật" là nỗ lực của tôi trong việc viết ruby, tôi sẽ cho rằng sự nhầm lẫn của họ phát sinh nhiều hơn từ sự thiếu hiểu biết về họ một phần hơn là thiếu rõ ràng về tôi. Điều đó không có nghĩa là quan điểm của bạn luôn không hợp lệ - nó chỉ là một điểm tốt khi bình luận ra mã. Nhưng nếu bình luận của bạn chỉ là ... bình luận ... thì cũng nên rõ ràng.
Bắn Parthian

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 vì tôi không có ý tưởng lồng nhau là một điều trong các bình luận đa dòng của Ruby.
Bắn Parthian

2
@ParthianShot - Đó không phải là một điều - = bắt đầu và = kết thúc bị bỏ qua nếu không ở đầu dòng. Làm tổ dường như là không thể.
skagedal

Việc lồng một bình luận bên trong một bình luận sẽ dẫn đến một bình luận hoặc một lỗi cú pháp từ việc cố gắng kết thúc một bình luận trong đó không có bình luận nào kết thúc. /*I am a\n#nested\ncomment, which really serves no purpose*/ /*I am bound /*to*/ FAIL!*/Sẽ có ý nghĩa nếu bạn có các nhận xét dòng đơn và mã bên trong một nhận xét nhiều dòng, chẳng hạn như một chức năng với tài liệu mà bạn không muốn mọi người sử dụng, nhưng bạn cũng không muốn xóa nó khỏi tệp.
Chinoto Vokro 24/07/2016

17

Sử dụng một trong hai

= bắt đầu
Điều này
Là
một
bình luận
khối
= kết thúc

hoặc là

# Điều này
# Là
# a
# bình luận
# khối

là hai cái duy nhất hiện đang được hỗ trợ bởi ndoc, đó là một lý do tốt để chỉ sử dụng những thứ này tôi nghĩ.


1
Một lý do chính đáng khác để bám vào =beginhoặc #là cả hai <<-DOC"cú pháp sẽ tạo ra các chuỗi ký tự vô dụng khi thực thi.
Cœur

13
=begin
(some code here)
=end

# This code
# on multiple lines
# is commented out

đều đúng Ưu điểm của loại bình luận đầu tiên là khả năng chỉnh sửa, dễ dàng bỏ qua hơn vì ít ký tự bị xóa. Ưu điểm của loại bình luận thứ hai là khả năng đọc được đọc từng dòng mã, dễ dàng hơn nhiều để nói rằng một dòng cụ thể đã được nhận xét. Cuộc gọi của bạn nhưng hãy nghĩ về những người đến sau bạn và việc họ đọc và duy trì dễ dàng như thế nào.


IMO, =begin=endkhông truyền tải một cách trực quan rằng những gì ở giữa là một nhận xét ... Clojure, ví dụ, sử dụng (comment :whatever)mà tại khách hàng tiềm năng nói lên ý nghĩa của nó: stackoverflow.com/questions/1191628/block-comments-in-clojure
David J.

1
Không "/ *" và "* /" trong Java, C và C ++. Cũng như cú pháp Ruby, các khối mã lớn có thể được nhận xét giữa hai ký tự đó và mọi người biết những điều cơ bản của ngôn ngữ đều biết ý nghĩa của chúng.
La-comadreja

1
Tô màu cú pháp (ví dụ trong vim) cho thấy loại đầu tiên là một nhận xét. Trong trường hợp đó, loại đầu tiên không có nhược điểm.
Camille Goudeseune

12

Đây là một ví dụ :

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

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

=end

Tất cả mọi thứ bạn đặt ở giữa =begin=endsẽ được coi là một nhận xét bất kể có bao nhiêu dòng mã nằm giữa.

Lưu ý: Đảm bảo không có khoảng cách giữa =begin:

  • Chính xác: =begin
  • Sai lầm: = begin

5

=begin comment line 1 comment line 2 =end chắc chắn = bắt đầu và = kết thúc là điều đầu tiên trên dòng đó (không có dấu cách)


2

Trong trường hợp ai đó đang tìm cách nhận xét nhiều dòng trong mẫu html trong Ruby on Rails, có thể có một vấn đề với = started = end, chẳng hạn:

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

sẽ thất bại vì%> đóng image_tag.

Trong trường hợp này, có thể tranh cãi liệu điều này có bình luận hay không, nhưng tôi thích kèm theo phần không mong muốn bằng một khối "nếu sai":

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

Điều này sẽ làm việc.


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

Lưu ý rằng tại thời điểm của bài đăng, công cụ stackoverflow không hiển thị màu cú pháp chính xác. Kiểm tra cách nó hiển thị trong trình soạn thảo lựa chọn của bạn là một bài tập. ;)

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.