Comentários de várias linhas no Ruby?


746

Como posso comentar várias linhas no Ruby?


7
No caso de alguém cair sobre esta procurando comentários de várias linhas em Puppet .ppmanifesta (que é baseado em um Rubi-como a sintaxe) você pode usar comentários em bloco C-estilo /**/
msanford

6
É bastante lamentável que comentários multilinhas em ruby ​​se pareçam muito com um bloco de código. E, considerando os pontos altos atribuídos a essa pergunta (e a resposta aceita), as pessoas que trabalham na sintaxe do rubi devem pensar claramente um pouco sobre isso.
25415 Nick

Respostas:


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.
  • É assim que parece (via captura de tela) - caso contrário, é difícil interpretar a aparência dos comentários acima. Clique para ampliar :

Comentários em um editor de texto


26
Eu realmente prefiro usar #sobre todos eles, principalmente porque separa visualmente as linhas comentadas melhor do que =begin/ =endou usando o método aqui. E bom trabalho.
the Tin Man

38
É interessante que essa resposta torne óbvias algumas falhas no marcador de sintaxe.
ZoFreX

69
Não se esqueça disso =begine =endnão pode ser precedido por nenhum espaço em branco.
bergie3000

15
E não é possível usar = begin = fim dentro de um método
Albert Català

7
É importante observar que no código de exemplo acima, apenas o primeiro =begin...=ende o último bloco usando #são capturados pelo rdoc ao gerar a documentação.
the Tin Man

126
=begin
My 
multiline
comment
here
=end

4
Claro, você poderia fazer isso. Funciona. Isso é incrivelmente raro. Eu acho feio. Talvez eu esteja preso no meu caminho?
David J.

53
Descobri que, se eu incluir uma guia antes de = begin ou = end, os comentários não funcionarão. Os itens = begin e = end precisam ser escritos no início de cada linha.
Rose Perrone

1
você não está sozinho @DavidJames. Pessoalmente, optei por tê-los todos comentados pelo meu editor. CMD + / ou ALT + / é a convenção para a maioria.
anon58192932

1
@DavidJames, o que você faria em vez disso? Digite a #e espaço antes de cada linha? São muitas as teclas digitadas, especialmente se eu começar a adicionar quebras de linha.
Paul Draper

57

Apesar da existência de =begine =end, a maneira normal e mais correta de comentar é usar #s em cada linha. Se você ler a fonte de qualquer biblioteca ruby, verá que é assim que os comentários de várias linhas são feitos em quase todos os casos.


4
Você pode obter argumentos sobre a parte "mais correta" da sua declaração, pois ambas são válidas. Eu prefiro usar #porque é mais óbvio. Ao comentar o código, é importante deixar óbvio que foi o que aconteceu. Se você estiver visualizando o código sem o benefício da coloração do código em um editor, =begin/=endpode ser difícil descobrir por que o código está sendo ignorado.
the Tin Man

6
Claro, existem muitas maneiras "válidas" de escrever comentários. Sejamos práticos aqui. Se você realmente escreve Ruby e lê o que os outros escrevem, deve usar #comentários. (Estou mistificada por que isso tinha duas downvotes Eu acho que a comunidade Stack Overflow tem para obtê-lo errado às vezes.!)
David J.

4
3 == threeonde def three; 1 + 1 + 1 end. Portanto, ambos são válidos. Quem se importa? Use 3!
David J.

1
@theTinMan Embora verdadeiro, geralmente a única vez em que você não destacaria a sintaxe (na minha experiência) é quando você está usando viem um servidor de produção. Nesse caso, você provavelmente não deveria estar desenvolvendo lá, de qualquer maneira.
Parthian Shot

1
@DavidJames Seu exemplo é ridículo porque é mais detalhado. Colocar um hash em cada linha é mais detalhado para comentários mais longos. E se alguém pensa que a frase "/ dev / urandom foi usada aqui para o PRNG criptograficamente com som não-bloqueante. Não toque nesse código - é mágico" é minha tentativa de escrever ruby, eu argumentaria que a confusão deles resulta mais da ignorância em seus parte do que falta de clareza na minha. O que não quer dizer que seu argumento seja sempre inválido - é apenas um bom argumento ao comentar o código. Mas se o seu comentário for apenas ... comentar ... deve ficar claro de qualquer maneira.
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 porque eu não fazia ideia de aninhar era uma coisa nos comentários multilinhas do Ruby.
Parthian Shot

2
@ParthianShot - Não é uma coisa - = begin e = end são ignorados, se não no início de uma linha. Aninhamento não parece ser possível.
skagedal

Aninhar um comentário dentro de um comentário resultaria em um único comentário ou em um erro de sintaxe ao tentar finalizar um comentário onde não há nenhum comentário final. /*I am a\n#nested\ncomment, which really serves no purpose*/ /*I am bound /*to*/ FAIL!*/Pode fazer sentido se você tiver comentários e código de linha única dentro de um comentário de várias linhas, como uma função com documentação que você não deseja que as pessoas usem, mas também não deseja removê-lo do arquivo.
Chinoto Vokro 24/07

17

Usando:

= começar
este
é
uma
Comente
quadra
= final

ou

# Esta
# é
# uma
# Comente
# quadra

são os dois únicos atualmente suportados pelo rdoc, o que é uma boa razão para usar apenas esses que eu acho.


1
Outra boa razão para furar a =beginou #é que tanto <<-DOCe "sintaxes irá gerar strings literais inúteis em execução.
Cœur

13
=begin
(some code here)
=end

e

# This code
# on multiple lines
# is commented out

ambos estão corretos. A vantagem do primeiro tipo de comentário é a capacidade de edição - é mais fácil remover o comentário porque menos caracteres são excluídos. A vantagem do segundo tipo de comentário é a legibilidade - ao ler o código linha por linha, é muito mais fácil dizer que uma linha específica foi comentada. Você telefona, mas pense em quem está atrás de você e em como é fácil para eles lerem e manterem.


A IMO =begine =endnão transmitem visualmente que o que está no meio é um comentário ... Clojure, por exemplo, usa o (comment :whatever)que nos leads diz o que significa: stackoverflow.com/questions/1191628/block-comments-in-clojure
David J.

1
Nem "/ *" e "* /" em Java, C e C ++. Como na sintaxe do Ruby, grandes blocos de código podem ser comentados entre esses dois caracteres, e todo mundo que conhece o básico da linguagem sabe o que significa.
La-comadreja

1
A coloração da sintaxe (no vim, por exemplo) mostra que o primeiro tipo é um comentário. Nesse caso, o primeiro tipo não tem desvantagens.
Camille Goudeseune 12/04/19

12

Aqui está um exemplo :

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

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

=end

Tudo o que você colocar no meio =begine =endserá tratado como um comentário, independentemente de quantas linhas de código ele contenha.

Nota: Verifique se não há espaço entre =e begin:

  • Corrigir: =begin
  • Errado: = begin

5

=begin comment line 1 comment line 2 =end verifique se = begin e = end é a primeira coisa nessa linha (sem espaços)


2

Caso alguém esteja procurando uma maneira de comentar várias linhas em um modelo html no Ruby on Rails, pode haver um problema com = begin = end, por exemplo:

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

falhará devido ao%> fechar o image_tag.

Nesse caso, talvez seja discutível se isso está sendo comentado ou não, mas eu prefiro incluir a seção indesejada com um bloco "se falso":

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

Isso vai funcionar.


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

Observe que, no momento da postagem, o mecanismo stackoverflow não processa a cor da sintaxe corretamente. Testar como é renderizado no seu editor de escolha é um exercício. ;)

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.