Commenti multilinea in Ruby?


746

Come posso commentare più righe in Ruby?


7
Nel caso in cui qualcuno cada in cerca di commenti multilinea nei .ppmanifest di Puppet (che si basa su una sintassi simile a Ruby) puoi usare i commenti di blocco in stile c /**/
msanford

6
È piuttosto spiacevole che i commenti multilinea in ruby ​​assomiglino molto a un blocco di codice. E visti gli alti punti assegnati a questa domanda (e alla risposta accettata) le persone che lavorano sulla sintassi ruby ​​dovrebbero chiaramente pensarci un po '.
Nick,

Risposte:


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.
  • Ecco come appare (tramite screenshot) - altrimenti è difficile interpretare come appariranno i commenti sopra. Fai clic per ingrandire :

Commenti in un editor di testo


26
Preferisco davvero #usarli sopra tutti, principalmente perché separa visivamente le righe commentate meglio di =begin/ =endo usando il metodo here-to. E, bel lavoro.
Tin Man,

38
È interessante notare che questa risposta rende evidenti alcuni difetti nell'evidenziatore della sintassi.
ZoFreX,

69
Non dimenticarlo =begine =endnon può essere preceduto da spazi bianchi.
Bergie3000,

15
E non è possibile usare = inizio = fine in un metodo
Albert Català

7
È importante notare che nel codice di esempio precedente, solo il primo =begin...=ende l'ultimo blocco utilizzati #vengono raccolti da rdoc durante la generazione della documentazione.
Tin Man,

126
=begin
My 
multiline
comment
here
=end

4
Certo, si potrebbe fare questo. Funziona. Questo è incredibilmente raro. Lo trovo brutto. Forse sono bloccato nei miei modi?
David J.

53
Ho scoperto che se includo una scheda prima di = inizio o = fine, i commenti non funzionano. = Inizio e = fine devono essere scritti all'inizio di ogni riga.
Rose Perrone,

1
non sei solo @DavidJames. Ho personalmente scelto di farli commentare tutti dal mio editore. CMD + / o ALT + / è la convenzione per la maggior parte.
anon58192932

1
@DavidJames, cosa faresti invece? Digitare a #e spazio prima di ogni singola riga? Sono molti i tasti premuti soprattutto se inizio ad aggiungere interruzioni di riga.
Paul Draper,

57

Nonostante l'esistenza di =begine =end, il modo normale e più corretto di commentare è usare quello #su ogni riga. Se leggi la fonte di qualsiasi libreria di ruby, vedrai che questo è il modo in cui vengono fatti i commenti su più righe in quasi tutti i casi.


4
Potresti ottenere argomenti sulla parte "più corretta" della tua dichiarazione poiché sono entrambi validi. Preferisco usare #perché è più ovvio. Nel commentare il codice è importante renderlo ovvio che è quello che è successo. Se stai visualizzando il codice senza il vantaggio della colorazione del codice in un editor, =begin/=endpuò essere difficile capire perché il codice viene ignorato.
Tin Man,

6
Certo, ci sono molti modi "validi" per scrivere commenti. Siamo pratici qui. Se in realtà scrivi Ruby e leggi cosa scrivono gli altri, dovresti usare i #commenti. (Sono sconcertato perché questo ha avuto due downvotes. Immagino che la comunità Stack Overflow debba sbagliare a volte!)
David J.

4
3 == threedove def three; 1 + 1 + 1 end. Pertanto entrambi sono validi. Che importa? Usa 3!
David J.

1
@theTinMan Sebbene sia vero, generalmente l'unica volta in cui manchi l'evidenziazione della sintassi (secondo la mia esperienza) è quando lo usi visu un server di produzione. In tal caso, probabilmente non dovresti fare il tuo sviluppo lì, comunque.
Parthian Shot

1
@DavidJames Il tuo esempio è ridicolo perché è più dettagliato. Inserire un hash su ogni riga è più dettagliato per commenti più lunghi. E se qualcuno pensa che la frase "/ dev / urandom sia stata usata qui per il PRNG non crittografato e dal suono crittografato. Non toccare questo codice, è magico" è il mio tentativo di scrivere ruby, direi che la loro confusione deriva più dall'ignoranza sul loro parte della mancanza di chiarezza sulla mia. Il che non vuol dire che il tuo punto non sia sempre valido, è solo buono quando si commenta il codice. Ma se il tuo commento è solo ... commento ... dovrebbe essere chiaro in entrambi i casi.
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 perché non avevo idea che l'annidamento fosse una cosa nei commenti su più righe di Ruby.
Parthian Shot

2
@ParthianShot - Non è una cosa - = inizio e = fine vengono ignorati se non all'inizio di una riga. La nidificazione non sembra essere possibile.
skagedal,

L'annidamento di un commento all'interno di un commento comporterebbe un singolo commento o un errore di sintassi dal tentativo di terminare un commento in cui non è presente alcun commento. /*I am a\n#nested\ncomment, which really serves no purpose*/ /*I am bound /*to*/ FAIL!*/Potrebbe avere senso se hai commenti a riga singola e codice all'interno di un commento su più righe, ad esempio una funzione con documentazione che non vuoi che le persone usino, ma che non vuoi anche rimuoverlo dal file.
Chinoto Vokro,

17

Utilizzando uno dei due:

= inizio
Questo
è
un'
commento
bloccare
= fine

o

# Questo
# è
# a
# commento
# blocco

sono gli unici due attualmente supportati da rdoc, che è una buona ragione per usare solo questi, penso.


1
Un altro buon motivo per attenersi =begino #è che entrambi <<-DOCe le "sintassi genereranno letterali stringa inutili durante l'esecuzione.
Cœur

13
=begin
(some code here)
=end

e

# This code
# on multiple lines
# is commented out

sono entrambi corretti. Il vantaggio del primo tipo di commento è la modificabilità: è più semplice rimuovere il commento perché vengono eliminati meno caratteri. Il vantaggio del secondo tipo di commento è la leggibilità: leggendo il codice riga per riga, è molto più facile dire che una determinata riga è stata commentata. La tua chiamata, ma pensa a chi ti verrà dietro e quanto sarà facile per loro leggere e mantenere.


IMO, =begine =endnon trasmettere visivamente che ciò che sta nel mezzo sia un commento ... Clojure, per esempio, usa ciò (comment :whatever)che ai lead dice cosa significa: stackoverflow.com/questions/1191628/block-comments-in-clojure
David J.

1
Nemmeno "/ *" e "* /" in Java, C e C ++. Come per la sintassi di Ruby, grandi blocchi di codice potrebbero essere commentati tra quei due caratteri e tutti quelli che conoscono le basi della lingua sanno cosa significano.
La-comadreja,

1
La colorazione della sintassi (ad esempio in vim) mostra che il primo tipo è un commento. In tal caso, il primo tipo non presenta svantaggi.
Camille Goudeseune,

12

Ecco un esempio:

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

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

=end

Tutto ciò che metti tra =begine=end verrà trattato come un commento indipendentemente da quante righe di codice contiene tra.

Nota: assicurarsi che non vi sia spazio tra =e begin:

  • Corretta: =begin
  • Sbagliato: = begin

5

=begin comment line 1 comment line 2 =end assicurati che = inizio e = fine sia la prima cosa su quella linea (nessuno spazio)


2

Nel caso in cui qualcuno stia cercando un modo per commentare più righe in un modello html in Ruby on Rails, potrebbe esserci un problema con = begin = end, ad esempio:

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

fallirà a causa della chiusura di%> tag_immagine.

In questo caso, forse è discutibile se questo sta commentando o no, ma preferisco racchiudere la sezione indesiderata con un blocco "if false":

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

Questo funzionerà.


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

Si noti che al momento del post, il motore stackoverflow non esegue correttamente il rendering della colorazione della sintassi. Testare come viene visualizzato nel tuo editor preferito è un esercizio. ;)

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.