Satu-satunya masalah yang tidak dapat diatasi adalah bersarang, tetapi inilah ide yang juga membahasnya. Bagaimana jika penumpukan didasarkan pada indentasi dan jumlah # karakter? Seperti di dalamnya mereka harus cocok agar bisa dipasangkan. Kemudian Anda dapat melakukan hal-hal seperti ini:

###
function foo(x,y)
  ###
    There seems to be an odd bug in the following
    very complex code that I have yet to discover
  ###
  while x < y
    # ...
  end
end
###

Di sini, Anda dapat dengan mudah menumpuk komentar multilini bagian dalam di dalam fungsi karena menjorok ke dalam, sedangkan komentar multilini luar yang menyembunyikan definisi fungsi seluruhnya berada di kiri.

#####
bar(x,y) = foo(x+y,y)

###
  Another multi-line comment
  that has no real content
###
baz(x,y) = foo(x,x+y)
#####

Dalam kasus ini, Anda memiliki komentar multiline yang bersarang di dalam yang lain dengan menggunakan sejumlah tanda pagar yang berbeda, memungkinkan Anda untuk dengan mudah mengomentari blok kode yang sudah memiliki komentar multiline di dalamnya, hanya dengan menggunakan lebih banyak tanda pagar.

Saya membayangkan bahwa Anda kebanyakan akan menggunakan ### untuk komentar multiline inline normal dan #### dan seterusnya untuk mengomentari blok kode, tetapi tentu saja, itu adalah konvensi yang terserah orang-orang yang melakukan coding. Ini hanya memfasilitasi itu.

Perhatikan bahwa tidak seperti komentar multiline /* ... */ style, Anda tidak perlu melacak pasangan yang seimbang untuk menangani penumpukan dengan benar: yang perlu Anda lakukan untuk menemukan pasangan penutup yang benar adalah indentasi pertandingan dan jumlah # . Jauh lebih sederhana.

Entahlah, menurut saya ini lebih sulit digunakan karena untuk mengomentari suatu wilayah, Anda harus melihat-lihat untuk menemukan jumlah # terbesar dan menambahkan 1. Tebakan saya adalah sepasang simbol simetris adalah yang paling mudah.

Mengapa kita tidak bisa menggunakan /* ... */ untuk komentar bertingkat, atau dalam hal ini ### ... ### ? Tidak bisakah ini ditangani seperti blok bersarang seperti di parser lainnya? Tidak bisakah kita memperlakukan komentar /* atau ### sebagai operator dan komentar sebagai kode? Ini dapat memungkinkan hal-hal keren lainnya di kemudian hari.

Saya dengan tegas menentang /* ... */ komentar, dan saya masih mendukung komentar ### . Saya mengerti maksud Jeff, tapi menurut saya itu bukan masalah besar. Sejujurnya, itu benar-benar perhatian editor, dan itu cukup ringan. Jadi editor Anda harus melakukan sedikit lebih banyak pekerjaan, secara potensial. Masa bodo. Bagi manusia, menurut saya skema ini sangat berguna dan estetis. Entah itu atau tidak ada komentar multiline sama sekali, yang, dengan dukungan editor yang layak, sebenarnya bukan masalah besar.

Saya tidak berpikir kami membutuhkan fitur mewah di sekitar komentar. Komentar sangat mudah diurai, jadi tidak terlalu sulit untuk menulis alat eksternal untuk mengekstrak dokumentasi.
Saya suka #| ... |# sebagai anggukan untuk cadel tapi saya tidak berharap orang lain menghargainya. Saya setuju ### terlihat bagus. Tapi untuk saat ini jangan lakukan apa-apa, dan tidurlah lebih lama.

Sepakat. Anda selalu dapat menambahkan gaya komentar baru (meskipun ### komentar tidak sepenuhnya kompatibel dengan versi sebelumnya), tetapi mengubah gaya komentar jauh lebih mengganggu. Jelas merupakan fitur v2.0 (jika pernah).

Editor bagus hari ini. Komentar multiline tidak terlalu diperlukan.

Saya baru mengenal Julia, diberi tahu melalui Slashdot. Menurut saya, menutup masalah ini bertentangan dengan manifesto " Mengapa Kami Menciptakan Julia ": Anda ingin membuat bahasa yang menyenangkan semua orang. "Editor bagus hari ini" tampaknya cukup angkuh untuk bahasa pemula dengan banyak janji ini; kurangnya komentar multiline di LaTeX (dan mulai {comment} tidak dihitung) adalah sumber frustrasi bagi saya, dan kekurangan serupa pada Julia akan menjadi penghalang bagi saya. IMO, kasus penggunaan dengan cepat menghapus / menambahkan kembali blok kode selama pengembangan jauh lebih besar daripada potensi kerusakan yang disebabkan oleh penggunaan sembarangan, dan memiliki manfaat tambahan karena tidak membuat pengguna menolak menjelajahi bahasa.

Kami tentu tidak pernah mengatakan bahwa kami "ingin menciptakan bahasa yang menyenangkan semua orang"; itu jelas tidak mungkin.

Izinkan saya menyatakannya kembali: Anda ingin menggabungkan fitur terbaik dari bahasa favorit Anda. Kecepatan C, dinamisme Ruby, dll ... dan kurangnya komentar multiline dari Python? Saya rasa saya tidak melihat alasan kuat untuk mengecualikannya (jika kurangnya waktu / minat pengembang, bukankah seharusnya permintaan fitur dibiarkan terbuka?).

Saya tidak sepenuhnya menentang ini. Saya pikir kami sebagian besar belum menemukan sintaks untuk itu yang sangat kami sukai.
Jika kita memilih sintaks untuk ini, sintaksnya akan bersarang dengan mudah, karena tampaknya itulah fitur yang disukai orang dalam komentar multiline.
Ada saran, @benkehoe ?

Posting blog membutuhkan sedikit lisensi artistik ... ini tidak dimaksudkan sebagai makalah ilmiah. Kami tidak benar-benar dinamis seperti ruby ​​(atau, tentu saja, secepat C pada umumnya), dan kami juga tidak hanya menggabungkan fitur bahasa lain.

Saya tidak bermaksud untuk menyatakan niat yang tepat kepada Anda dalam salah satu komentar saya, hanya gagasan umum bahwa bahasa pekerja keras yang baik harus memiliki komentar multiline (dan komentar satu baris, seperti yang akhirnya diingat C setelah 20 tahun). Menurut saya, jika penumpukan diinginkan, sintaksnya harus berupa _like_ /* ... */ , yaitu, dengan penanda awal dan akhir yang berbeda. # harus terlibat karena ini adalah "karakter komentar". #| ... |# tidak buruk, meskipun mungkin tanda kurung dari beberapa jenis akan lebih baik, baik interior seperti #( ... )# atau gaya MATLAB #( ... #) , meskipun saya rasa Anda bisa mengalami masalah saat berkomentar keluar argumen atau pengindeksan.

Bagaimana dengan ini:

#begin
  This is a comment.
#end

Saya masih sangat menyukai skema komentar multiline asli yang diturunkan dari CoffeeScript. Jika seseorang membutuhkan indentasi dan nomor karakter # untuk dicocokkan, ini sangat dapat disarangkan tanpa memerlukan penguraian yang sebenarnya.

#begin/#end sepertinya banyak mengetik. Saya pikir ### bagus, kecuali untuk bit bersarang: tidak ada bahasa lain yang sadar spasi, bukan? Saya tidak keberatan dengan komentar blokir yang tidak dapat @JeffBezanson mungkin itulah yang dicari orang. Jumlah yang bervariasi (> = 3) dari # versi mungkin akan mudah digunakan jika Anda meninggalkan bagian indentasi. Apa yang salah dengan #| ... |# ?

Setiap #x x# combo terlihat aneh bagi saya. Cobalah di beberapa baris:

#|
  comment here
|#

tidak ada komentar multi baris yang baik, jika sangat menginginkannya, / * * / tidak apa-apa

Dari semua kemungkinan, saya paling suka ###.

@ViralBShah , maksudmu tidak bersarang? Hal lain dengan indentation-nesting adalah merusak kemampuan editor untuk melakukan indentasi kode secara otomatis. @StefanKarpinski , mengapa Anda memerlukan indentasi _dan_ jumlah karakter untuk mempermudah penguraian? Bukankah jumlah karakter cukup?

### memang terlihat bagus. Tetapi jika ada sejumlah #, itu mencegah bentuk umum dari komentar seni ASCII :)
Mungkin bersarang tidak terlalu penting. Kita bisa mulai dengan ### dan menambahkan versi bersarang jika diperlukan. Atau kita bisa menggunakan ###{ }### untuk bersarang; mungkin jika seseorang benar-benar peduli tentang bersarang mereka tidak akan keberatan dengan keburukannya.

Sepertinya itu cukup masuk akal.

(untuk kesenangan menonton Anda)

Jika Anda memilih untuk menggunakan pasangan karakter tab untuk komentar multiline, gunakan pasangan tab untuk komentar multiline bertingkat.
Kesederhanaan keputusan itu menawarkan harmoni pengguna. Anda seharusnya tidak peduli seberapa relatif indentasi pasangan bersarang.

menggunakan pasangan treble octothorpe

###
   one, two, three
   three twenty one
###

###
      # one, two, three 
      three twenty one
   ###
     one, two, three 
     three twenty one
   ###
###

menggunakan pasangan vertical_bar octothorpe

#|
   one, two, three
   three twenty one
|#

#|
      # one, two, three 
      three twenty one
   #|
     one, two, three 
     three twenty one
   |#
|#

menggunakan pasangan tanda seru octothorpe

#!
   one, two, three
   three twenty one
!#

#!
      # one, two, three 
      three twenty one
   #!:
     one, two, three 
     three twenty one
   !#
!#

menggunakan pasangan titik dua octothorpe

#:
   one, two, three
   three twenty one
:#

#:
      # one, two, three 
      three twenty one
   #:
     one, two, three 
     three twenty one
   :#
:#

Saya pribadi paling suka opsi ### menjorok ke dalam. Tampak intuitif, mudah diketik, dan simetris. #begin / #end merupakan opsi yang bagus, karena mereka akan sejalan dengan sintaks bahasa lainnya, dan akan memungkinkan penyarangan tanpa membuatnya bergantung pada spasi.

Saya tidak suka #( ... )# dan opsi serupa, karena itu merusak simetri (seperti yang Stefan katakan, konstruksi #x ... x# terlihat jauh lebih baik sebaris daripada sebenarnya mencakup banyak baris), dan membuatnya lebih sulit untuk mengaktifkan komentar multiline ( opsi di atas hanya memerlukan penyisipan / penghapusan spasi setelah karakter # pertama untuk mengubahnya menjadi komentar satu baris biasa).

FYI, plugin editor kate sekarang dapat "melipat" komentar yang dikurung oleh #BEGIN ... # END (saran dari orang-orang KDE). Pilihan ini tentu saja bisa berubah, dan saya suka huruf kecil. Dimaksudkan untuk mengiklankan / meminta masukan, tapi saya sudah terlalu sibuk, jadi saya rasa inilah kesempatannya.

Saya lebih suka #bgn .. #end (menurut saya panjang tag yang cocok membuat pemindaian visual lebih menyenangkan).

Sekalipun demikian, saya lebih suka menyalin cara Julia mendemarkasi komentar multiline :-)

Meskipun rapi, balok lain tidak cocok dengan panjangnya dengan end . for , let dan try kebetulan melakukannya, tetapi while , function , dll tidak, jadi disingkat menjadi #bgn akan merusak pola saat ini.

cukup benar

Saya akan senang memiliki banyak komentar sebagai bagian dari Julia dengan apa pun
pemasangan.

_begin ... end_ tidak memperkenalkan ruang lingkup baru - mungkin _ # mulai .. * _

akhir * juga tidak. Jika terjadi kasus yang memperlakukan multiline

komentar sebagai ruang lingkup yang berbeda sangat membantu, maka saya lebih suka _ # cmt_ * ... # *
_end_ atau (jika mempertahankan token set saat ini penting) _ # let ... #end_.

Pada Kamis, 1 Nov 2012 pukul 18:28, Waldir [email protected] menulis:

Meskipun rapi, balok lain tidak cocok panjangnya dengan ujungnya. untuk, letand
mencoba kebetulan melakukannya, tetapi while, function, dll tidak, jadi singkatnya

bgn akan merusak pola saat ini.

-
Balas email ini secara langsung atau lihat di Gi tHubhttps: //github.com/JuliaLang/julia/issues/69#issuecomment -9998478.

Saya baru-baru ini melihat komentar multiline untuk DSL. Satu masalah yang saya temui adalah bahwa ketika memindai melalui kode yang disorot non-sintaks, itu membantu untuk memiliki pembukaan yang berbeda pada string penutup. Akhirnya saya menggunakan yang berikut ini:

msg = "Hello."
----
Nesting is done using additional characters
---
I really don't have a complex code example to 
write but somehow I have lots of things to say about it.
===
====
println(msg)

Beberapa pemikiran:

Satu masalah yang dapat muncul dengan ### adalah ketika Anda memiliki 3 lapis komentar baris tunggal, yang menurut saya tidak sering terjadi tetapi kadang-kadang masih terjadi:

# foo()
## for i = 1:3
###     baz() # Hu-ho, where is the closing symbol?
##     buzz()
## end

Paradoksnya, komentar multiline sering kali berguna pada satu baris seperti ini:

f(x, /* y, */ z) // I want to try f without this argument... quick and dirty
f(/* unused */ x, y) // inlined comment

Anda juga bisa melakukannya dengan satu baris komentar:

f(x,
#  y,
  z)
f(x, # unused
  y)

tetapi pendekatan pertama terkadang berguna.

Saya pikir pasangan #(# - #)# akan cukup rapi. Demo:

f(x, #(# y, #)# z)

foo()
#(#
for i = 1:3
  #(#
     baz()
     baz2()
  #)#
     buzz()
end
#)#

Manfaat:

• karakter # membuatnya terlihat seperti komentar
• tanda kurung membuat simbol pembuka dan penutup yang jelas dan ringkas
• karakter # membuatnya terlihat lebih baik (quasi-symetric) terutama jika ditulis di barisnya sendiri
• karena simbol pembuka dan penutup berbeda, mereka harus mudah diurai dan penyarangan dapat diizinkan

Preferensi awal Jeff baik-baik saja bagi saya.
# | ... | #

Jika pilihan antara pasangan 3 karakter dan pasangan 2 karakter, saya
lebih memilih yang tidak terlalu mengganggu secara visual.

Pada hari Jumat, 30 November 2012 pukul 19.32, Simon Leblanc [email protected] :

Beberapa pemikiran:

Satu masalah yang bisa muncul dengan ### adalah ketika Anda memiliki 3 lapisan tunggal
baris komentar, yang menurut saya tidak sering tetapi masih terjadi
terkadang:

foo ()

untuk i = 1: 3

baz () # Hu-ho, dimana simbol penutupnya?

berdengung()

akhir

---

Paradoksnya, komentar multiline seringkali berguna pada satu baris seperti
ini:

f (x, / * y, _ / z) // Saya ingin mencoba f tanpa argumen ini ... cepat dan kotor
f (/ _ unused * / x, y) // komentar sebaris

Anda juga bisa melakukannya dengan satu baris komentar:

f (x,

y,

z)
f (x, # tidak terpakai
y)

tetapi pendekatan pertama terkadang berguna.

Saya pikir pasangan # (# - #) # akan cukup rapi. Demo:

f (x, # (# y, #) # z)

foo ()

(

untuk i = 1: 3
# (#
baz ()
baz2 ()
#) #
berdengung()
akhir

)

Manfaat:

• karakter # membuatnya terlihat seperti komentar
• tanda kurung membuat simbol pembuka dan penutup yang jelas dan ringkas
• karakter # terakhir membuatnya terlihat lebih baik (quasi-symetric)
  terutama jika ditulis di barisnya sendiri
• karena simbol pembuka dan penutup berbeda, seharusnya mudah
  untuk mengurai dan bersarang dapat diizinkan

-
Balas email ini secara langsung atau lihat di Gi tHubhttps: //github.com/JuliaLang/julia/issues/69#issuecomment -10909823.

Saya akan mengatakan bahwa jika saya menambahkan ini, satu-satunya hal yang akan saya pertimbangkan adalah sesuatu seperti # | | # atau # () #, karena bersarang dan tidak bertentangan dengan seni ASCII yang terbuat dari #, yang harus didukung :)

Ini adalah tempat bersepeda terbesar yang pernah ada.

Dari keduanya, # () # lebih mudah diketik (sedikit gerakan tangan).

Pada hari Jumat, 30 November 2012 pukul 20.26, Jeff Bezanson [email protected] :

Saya akan mengatakan bahwa jika saya menambahkan ini, satu-satunya hal yang akan saya pertimbangkan adalah
sesuatu seperti # | | # atau # () #, karena mereka bersarang dan tidak konflik dengan
Seni ASCII terbuat dari #, yang harus didukung :)

-
Balas email ini secara langsung atau lihat di Gi tHubhttps: //github.com/JuliaLang/julia/issues/69#issuecomment -10911146.

Ini adalah tradisi desain bahasa untuk memiliki perdebatan yang sangat panjang tentang sintaks komentar :)

#| dan |# akan sangat menarik jika kita dapat melakukan #|# untuk komentar "mandiri". Itu akan memungkinkan mengubah komentar dengan mengetik (atau menghapus) hanya dua karakter.

komentar sebaris:
f(x, #| y, |# z)
komentar sebaris dinonaktifkan:
f(x, #|# y, #|# z)

komentar multiline:

foo()
#|
for i = 1:3
  #|
     # baz()
     baz2()
  |#
     buzz()
end
|#

komentar multiline dinonaktifkan:

foo()
#|#
for i = 1:3
  #|
     # baz()
     baz2()
  |#
     buzz()
end
#|#

Ngomong-ngomong, karakter simetris lainnya bisa jadi menarik, seperti : (yang menurut saya lebih menarik secara visual) atau * (yang meminjam dari // dan /* ... */ model)

Sebenarnya, saya suka ini:

#=
  Comment here
=#

Terasa sedikit terinspirasi oleh POD dan bermain baik dengan seni ASCII, misalnya #======== . Kami dapat mengizinkan #=# sebagai komentar penutup diri.

Pada 1 Des 2012, 19.05, "Stefan Karpinski" [email protected] menulis:

Sebenarnya, saya suka ini:

=

Beri komentar di sini
= #

Terasa sedikit terinspirasi oleh POD dan cocok dengan seni ASCII, misalnya

========. Kami dapat mengizinkan # = # sebagai komentar penutup diri.

+1

1 untuk PHP-ification komentar Julia.

Apa itu PHP-ification? Apakah PHP melakukan ini untuk komentar multiline?

Pertanyaan kebetulan. Jika Anda ingin memiliki komentar multiline, mungkin sebagian dari tujuannya adalah agar dapat memberikan komentar pada potongan kode yang berubah-ubah. Itu gagal jika Anda memiliki karakter komentar penutup dalam string atau komentar tambahan. Jika kami membuat komentar dapat bersarang, membuka komentar di string dan komentar tambahan juga menjadi masalah. Contoh:

#=
"=#"
# =#
=#

Jadi pertanyaannya adalah seberapa sadar sintaks kita membuat komentar multiline? Kecenderungan saya adalah membuatnya agak sadar sehingga semua hal ini "berjalan lancar", tapi itu pasti jauh lebih rumit.

atau versi yang terinspirasi dari juila-set: ~)

~

  comment here

~ #

mengizinkan # ~ # sebagai komentar penutup diri

Pada hari Sabtu, 1 Desember 2012 jam 13.09, John Myles White
[email protected] :

1 untuk PHP-ification komentar Julia.

-
Balas email ini secara langsung atau lihat di Gi tHubhttps: //github.com/JuliaLang/julia/issues/69#issuecomment -10920019.

PHP tidak melakukan ini dengan komentar. Saya baru saja mengomentari kemiripan visual dengan template HTML gaya PHP dengan entri <%= =%> .

Benar, benar. Saya benar-benar suka #= ... =# yang aneh karena sepertinya saya benci kebanyakan proposal komentar multiline karena beberapa alasan.

Saya harus mengatakan bahwa dari semua alternatif yang pernah saya lihat, saya paling suka #= ... =# .

=

 well, wrap me up in
 #=  and call me  =#
 comfortably swathed

= #

Pada hari Sabtu, 1 Desember 2012 jam 21:43, Viral B. Shah [email protected] :

Saya harus mengatakan bahwa dari semua alternatif yang pernah saya lihat, saya suka # = ... = # the
paling.

-
Balas email ini secara langsung atau lihat di Gi tHubhttps: //github.com/JuliaLang/julia/issues/69#issuecomment -10925287.

@Tokopedia apakah masalah untuk memiliki parser yang mengetahui apa itu string sebelum mengetahui apa itu komentar pembuka / dekat?

Ini bisa dilakukan, tetapi agak aneh karena itu berarti string di dalam komentar akan bermakna. Jadi, Anda sedang mengurai konten komentar. Kalau dipikir-pikir, mungkin ini harus diintegrasikan dengan fungsionalitas doc string.

= = # mengingatkan saya pada upaya ekstra (baca, tungkai, dan pikirkan emacs) yang dibutuhkan, sebagai lawan mengatakan, simbol prime '' 'sederhana: http://en.wikipedia.org/wiki/Prime_%28symbol%29 # Use_in_mathematics.2C_statistics.2C_and_science

Apa salahnya menggunakan '' '' '' sebagai docstring?

Saya tidak terlalu peduli format apa yang digunakan, tetapi saya ingin memberikan suara untuk komentar multi-baris. Meskipun penggunaannya sebagai docstrings sepertinya akan sulit karena begitu banyak metode julia didefinisikan sebagai kasus khusus dari metode lain seperti f(a,b,c) = f((a,b), d(c))

Bagaimana dengan menggunakan makro kosong <strong i="5">@comment</strong> begin ..... end untuk komentar multiline?

macro comment(b) end

Masalahnya adalah blok komentar harus benar secara sintaksis, tetapi tidak masalah jika Anda ingin mengabaikan bagian kode untuk pengujian.

Bagaimana dengan menyatukan satu baris dan memblokir komentar. Karakter komentar # dapat digunakan untuk menunjukkan awal dari kedua jenis komentar, dan menghasilkan komentar baris tunggal jika tidak diikuti oleh tag penghentian, misalnya, /# .

Contoh:

# This is a single-line comment.

# This is a block comment,
  consisting of two lines. /#

# Block comments are a useful tool
foo(a, #b,/# c)

Keuntungannya adalah tidak bergantung pada spasi, yang konsisten dengan Julia lainnya, memungkinkan untuk komentar bertingkat, dan sifatnya yang terpadu memungkinkan Anda untuk mengomentari seluruh blok kode secara efisien dengan mengetikkan dua karakter. Sebagai contoh:

# This is an example code block
foo()
bar()

dengan cepat dibatalkan oleh

# This is an example code block
foo()
bar() /#

Tampaknya komentar banyak baris biasanya digunakan karena salah satu dari dua alasan berikut:
kasus 1: Dokumentasi kode
kasus 2: Mengosongkan blok kode

Berkenaan dengan kasus 1, mungkin yang terbaik adalah memilih sintaks yang Anda tahu akan ramah pembuat dokumen, atau menyediakan mekanisme khusus seperti string doc Python. (Saya sebenarnya menyukai yang terakhir, tapi itu hanya pendapat saya.)

Berkenaan dengan use case 2, haruskah penggunaan ini benar-benar didorong? Kami memiliki kontrol versi, yang memungkinkan seseorang untuk menghapus blok kode, dengan hati-hati mendokumentasikan mengapa mereka melakukannya, dan kemudian mengembalikan tindakan itu jika perlu. Kami memiliki makro, yang berpotensi dapat mengaktifkan / menonaktifkan mekanisme debug seperti pernyataan dan pernyataan cetak dengan lebih elegan daripada komentar multi baris.

Python menyediakan dua mekanisme berbeda untuk dua kasus ini:

1. string ekspresi literal untuk dokumentasi kode, yang bisa multi-baris dengan tanda kutip tiga ( """ atau ''' )
2. # untuk mengosongkan blok kode, yang tidak bisa multi-baris (tapi mudah dilakukan di blok oleh editor)

Pendekatan ini memiliki keuntungan untuk setiap kasus:

1. string dokumentasi secara visual berbeda dari kode yang diberi komentar, terutama dengan penyorotan sintaks
2. sangat jelas secara visual kode apa yang kosong, bahkan tanpa penyorotan sintaks

Tidak masalah menggunakan operator simetris """ untuk dokumen multi-baris, karena mereka tidak perlu disarangkan.

Jika operator asimetris untuk komentar multi-baris benar-benar diinginkan, saya merekomendasikan sesuatu yang arahnya sangat jelas secara visual: bukan untuk #| |# atau #= =# , tetapi untuk <# #> .

Saya akan memilih <# #> lebih dari #( )# atau (# #) karena tanda kurung memiliki arti matchfix sendiri, dan dapat diartikan sebagai terpisah.

<#
  function foo(n)
  """
  foo docstring
  """
    # return 1    # blanked out
    "returns zero"
    return 0
  end
#>

Jika literal string biasa "..." diizinkan sebagai docstrings, pengguna harus menghindari menjadikannya ekspresi terakhir dalam suatu fungsi (karenanya nilai kembaliannya). Karena kebanyakan docstring mengacu pada kode berikut, batasan ini tampaknya baik-baik saja, dan menjaga semua perilaku tetap konsisten.

<# adalah pengenal < diikuti dengan komentar baris, jadi itu tidak akan berhasil. Saya akan mengatakan sesuatu seperti #= =# cukup intuitif, karena dengan cara itu semua komentar dimulai dengan # .

Intuitifitas <# masih bisa diperdebatkan - Saya membacanya sebagai penanda penutup pasangan, seperti dalam #> comment <# - yang sebenarnya akan berfungsi sebagai pasangan pembatas komentar. Masih seperti #= comment =# terbaik.

Akhir penutupan #| |# juga dimulai dengan pengenal, tetapi saya mengasumsikan penguraian khusus untuk komentar.

Ambiguitas arah dari <# #> tidak terpikir oleh saya. Saya tidak bisa memikirkan simbol QWERTY terarah jelas lainnya yang belum digunakan dalam sintaks matchfix, jadi mungkin simbol itu ada di sana.

Sebagai catatan, saya tidak yakin bahwa komentar multi-baris adalah ide yang bagus, mengingat keuntungan 2 yang disebutkan di atas. Python tampaknya lebih bersih tanpa mereka.

Tetapi Python memiliki docstrings, yang pada dasarnya seperti komentar multiline. Non-lokalitas yang saya pribadi tidak suka tentang komentar multiline direplikasi oleh docstrings.

Saya selalu merasa bahwa string dokumen di python agak lepas. Mengapa saya tidak bisa hanya memiliki string dalam konteks kosong? Itu ekspresi yang sangat valid, meskipun salah satu kegunaannya terbatas. Ada juga banyak masalah bermasalah yang tidak muncul di Python yang muncul di Julia, yang jauh lebih liberal dengan string - seperti Ruby atau Perl:

• Apa yang terjadi jika ada interpolasi di dalam string dokumen?
• Bagaimana jika interpolasi itu memiliki efek samping?
• Bagaimana jika interpolasi bergantung pada argumen fungsi?
• Bagaimana Anda mengevaluasi string dokumen tanpa nilai untuk argumen?
• Atau hanya string dalam konteks kosong dan bukan dokumen jika tidak mengandung interpolasi?
• Atau apakah itu kesalahan untuk memiliki interpolasi dalam sesuatu yang dapat ditafsirkan sebagai string dokumen?
• Bagaimana jika string doc adalah ekspresi terakhir dalam fungsi?
• Apakah itu berarti saya tidak dapat secara implisit mengembalikan string multi-baris menggunakan interpolasi?

Ini tidak muncul di Python karena Python tidak memiliki interpolasi dan membutuhkan pengembalian eksplisit.

function imamonster!(arg)
  """
  imamonster! – $(arg)!
  $(println("Hello, world."))
  """
end

Jika Anda menginginkan dokumentasi inline, tidak ada keuntungan mencuri formulir ekspresi yang valid daripada menggunakan konvensi komentar tertentu. Jika Anda menggunakan konvensi komentar, setidaknya jika Anda tidak mengetahui konvensi tersebut, Anda tidak akan menafsirkan sesuatu yang salah, Anda hanya tidak akan mengetahui dokumentasinya.

@johnmyleswhite - dapatkah Anda menguraikan masalah non-lokalitas?

Bagi saya, non-lokalitas tampaknya baik-baik saja untuk docstrings karena (a) pembaca dapat dengan mudah membedakannya dari kode, dan (b) tidak bersarang. Hanya dengan melihat mereka, pembaca tahu bahwa mereka tidak pernah dieksekusi, dan secara visual dapat melihat di wilayah mana mereka berasal.

Non-lokalitas adalah masalah dengan kode multi-baris yang dikomentari, karena hanya melihat satu baris kode tidak memberi tahu Anda apakah itu dijalankan atau tidak, atau wilayahnya seperti itu.

Stefan, non-lokalitas hanya berarti Anda tidak dapat mengurai satu baris pun tanpa melihat sesuatu yang mungkin telah terjadi ratusan baris sebelumnya. Ini sering terjadi di pustaka Python, di mana docstring meluas ke banyak halaman.

Thomas, Anda pasti benar: mungkin bagi sebagian besar baris untuk menentukan bahwa itu bukan kode, meskipun contoh sesekali yang dimasukkan ke dalam docstring terkadang akan memecahkannya. Hal yang membuat saya gila adalah bahwa docstrings memperkenalkan wilayah dengan ruang putih ad hoc, yang membuatnya sangat sulit untuk memanipulasinya menggunakan hal-hal seperti multikursor.

Bagaimanapun, cukup banyak orang yang menginginkan komentar multiline (yang memiliki masalah interpretasi yang aneh) sehingga kita harus memilih pembatas yang waras dan menerapkannya.

Hanya dengan melihat mereka, pembaca tahu bahwa mereka tidak pernah dieksekusi,

Bagaimana itu? Sebuah string adalah ekspresi valid sempurna di Julia dengan nilai valid yang dihasilkan saat dieksekusi. Itu juga benar di Python, btw, itulah sebabnya saya selalu berpikir string dokumen agak samar.

Akhir penutup # | | # juga dimulai dengan pengenal, tetapi saya mengasumsikan penguraian khusus untuk komentar.

Bagian penutup yang dimulai dengan pengenal bukanlah masalah - ini adalah bagian akhir yang menjadi masalah.

Sebuah string adalah ekspresi valid sempurna di Julia dengan nilai valid yang dihasilkan saat dieksekusi. Itu juga benar dengan Python

Saya percaya kompiler Python mengoptimalkan literal string tunggal, sehingga mereka tidak ada secara efektif.

Jika Anda menggunakan konvensi komentar, setidaknya jika Anda tidak mengetahui konvensi tersebut, Anda tidak akan menafsirkan sesuatu yang salah, Anda hanya tidak akan mengetahui dokumentasinya.

Mungkin saya salah paham, tetapi saya akan mengatakan sebaliknya: jika Anda menggunakan string literal sebagai docstrings, maka (kecuali untuk kasus ekspresi-terakhir-dalam-fungsi) Anda akan menafsirkan program dengan benar bahkan jika Anda tidak mengetahui konvensi tersebut , sementara tidak mengetahui dokumentasinya. Jika Anda menggunakan sintaks tambahan, Anda harus menyadarinya untuk menafsirkan program dengan benar.

Akhir penutup yang dimulai dengan pengenal bukanlah masalah

Seperti yang saya katakan, saya sedang mempertimbangkan ini dari perspektif kegunaan dan keterbacaan, dengan asumsi pengurai akan memperlakukan kombinasi ini secara khusus. Jika sebaris kode diakhiri dengan pengenal | , memulai komentar baris tunggal segera setelahnya akan terlihat seperti penutup |# .

Apa yang dilakukan atau tidak dioptimalkan oleh compiler tidak relevan dengan semantik bahasa - jika tidak, ini tidak akan menjadi pengoptimalan, ini akan menjadi bagian bahasa yang signifikan secara semantik.

Yang saya maksud adalah jika dokumentasi literasi disediakan sebagai jenis komentar khusus, seperti:

# foo(x) – compute the foo transform of `x`
#
function foo(x)
  # do stuff
end

Misalnya, konvensi adalah bahwa komentar yang mengarah ke fungsi atau definisi metode dikaitkan dengan mereka sebagai dokumentasi, maka data ini jelas tidak mempengaruhi eksekusi karena meskipun Anda tidak tahu apa-apa tentang komentar dokumen, ini masih jelas a komentar.

Bagaimanapun, string doc Python adalah non-starter untuk Julia karena semua masalah yang saya sebutkan di atas.

Dokumen gaya pengkodean kernel Linux (https://www.kernel.org/doc/Documentation/CodingStyle) menyatakan bahwa gaya yang disukai untuk komentar panjang (multi-baris) adalah:

/*
 * This is the preferred style for multi-line
 * comments in the Linux kernel source code.
 * Please use it consistently.
 *
 * Description:  A column of asterisks on the left side,
 * with beginning and ending almost-blank lines. 
 */

Saya juga telah melihat ini di banyak proyek C dan C ++ lainnya. Sepertinya saya ingat membaca panduan gaya C ++ yang merekomendasikan bahwa // digunakan untuk semua komentar (termasuk komentar multi-baris), tetapi sepertinya saya tidak dapat menemukan referensi sekarang. Dokumen Linux tidak memberikan alasannya; namun, saya biasanya melakukan ini sehingga ketika karakter utama / * berguling dari layar di bagian komentar yang panjang, masih jelas bahwa saya sedang melihat blok komentar. (Mungkin inilah maksud @johnmyleswhite .)

Intinya di sini adalah bahwa C memberikan komentar multi-baris, namun banyak programmer C tidak benar-benar menggunakannya dengan cara itu.

Berdasarkan ini, saya cenderung menyimpulkan hal berikut tentang programmer Julia di masa depan: Jika Julia memberikan dukungan komentar multi-baris (setara dengan / * * /), sebagian pengguna Julia yang tidak sepele tidak akan menggunakannya . Yang berarti bahwa ketika tiba saatnya untuk membuat proyek menggunakan banyak paket, kami akan memiliki campuran format komentar multi-baris. Artinya, kita akan lihat

/*
 * stuff like
 * this
 */

dan

/*
stuff like
this
*/

Sebagai catatan tambahan, satu hal yang menyenangkan tentang / * * / comments adalah kemampuannya untuk memasukkan komentar sebaris; misalnya

int foo(x, /* doc meaning of x */
          y, /* doc meaning of y */
          z, /* doc meaning of z */);

Tentu saja, dalam contoh ini, / * * / tidak digunakan sebagai komentar "beberapa baris", tetapi sesuatu yang berbeda ("komentar sebaris"?).

Coffeescript bagus

#

bla

#

http://coffeescript.org/#strings

Pada Kamis, 5 Sep 2013 jam 20:37, Benjamin Silbaugh
[email protected] :

Dokumen gaya pengkodean kernel Linux (
https://www.kernel.org/doc/Documentation/CodingStyle) menyatakan bahwa file
gaya yang disukai untuk komentar panjang (banyak baris) adalah:

/ *

• Ini adalah gaya yang disukai untuk banyak garis
• komentar di kode sumber kernel Linux.
• Silakan gunakan secara konsisten.
  *
• Deskripsi: Kolom tanda bintang di sisi kiri,
• dengan awal dan akhir baris yang hampir kosong.
  * /

Saya juga telah melihat ini di banyak proyek C dan C ++ lainnya. Sepertinya saya ingat
membaca panduan gaya C ++ yang merekomendasikan bahwa // digunakan untuk semua komentar
(termasuk komentar multi-baris), tetapi sepertinya saya tidak dapat menemukan referensinya
sekarang juga. Dokumen Linux tidak memberikan alasannya; bagaimanapun, saya
biasanya akhirnya melakukan ini sehingga ketika karakter utama / * berguling
layar di bagian komentar yang panjang, masih jelas yang saya lihat
blok komentar. (Mungkin inilah yang @johnmyleswhitehttps : //github.com/johnmyleswhitewas.)

Intinya di sini adalah bahwa C memberikan komentar multi-baris, namun banyak C
programmer tidak benar-benar menggunakannya dengan cara itu.

Berdasarkan ini, saya cenderung menyimpulkan hal berikut tentang Julia di masa depan
programmer: Jika Julia menyediakan dukungan komentar multi-baris (yang setara
dari / * * /), subset non-sepele dari pengguna Julia tidak akan menggunakannya
Itu. Yang berarti ketika tiba waktunya untuk membuat proyek menggunakan banyak
paket, kami akan memiliki campuran format komentar multi-baris. Artinya, kami akan
Lihat

/ *

• hal-hal seperti
• ini
  * /

dan

/ *
hal-hal seperti
ini
* /

Sebagai catatan tambahan, satu hal yang menyenangkan tentang / * * / comments adalah kemampuannya
komentar sebaris; misalnya

int foo (x, / * doc arti dari x _ /
y, / _ doc arti dari y _ /
z, / _ doc arti dari z * /);

Tentu saja, dalam contoh ini, / * * / tidak digunakan sebagai "multi-baris"
komentar, tetapi sesuatu yang berbeda ("komentar sebaris"?).

-
Balas email ini secara langsung atau lihat di Gi tHubhttps: //github.com/JuliaLang/julia/issues/69#issuecomment -23911810
.

Dr Rahul Dave
ADS, Pusat Astrofisika
Universitas Harvard
[email protected]
(રાહુલ દવે)

Dan kami telah mencapai lingkaran penuh. Saya sedang mempertimbangkan untuk menutup masalah sekarang dan berpura-pura itu hanya troll epik selama ini.

+1 untuk # = = #, karena ini adalah pilihan yang disukai oleh penyeleksi dan akan lebih baik diputuskan sebelum menutup

Hai,

Saya baru mengenal Julia, jadi pertanyaan ini mungkin agak terlambat. Tapi mungkin itu masih relevan. Apakah Anda akan mempertimbangkan untuk menambahkan mekanisme untuk mengomentari seluruh blok, misalnya, sesuatu yang analog dengan "#;" Skema? Artinya, operator - sebut saja "@ #" - sedemikian rupa

@ # dimulai
...
akhir

akan mengomentari seluruh blok (dan juga untuk jenis struktur blok lainnya). Saya sering menemukan ini berguna dalam debugging.

@ # hanyalah ide pertama yang muncul, karena tampaknya perilaku benda ini seperti makro. Memang, seseorang dapat dengan mudah menulis makro yang menggantikan blok tertentu dengan sesuatu yang tidak berbahaya, meskipun ini tidak akan benar secara semantik jika blok yang dimaksud berada di akhir, katakanlah, definisi fungsi. Juga, beberapa bentuk ini mungkin berguna di dalam ekspresi matematika, meskipun secara alami ada beberapa ambiguitas yang harus diselesaikan, dan ini akan sulit dilakukan dengan makro.

Jika hal ini telah dibahas di tempat lain, atau pada kenyataannya dibahas & ditolak, beri tahu saya. Maaf memperpanjang diskusi yang sudah berjalan lama ini. :-)

Bersulang,
KL

1 untuk komentar multiline. Pilihan apa pun tidak masalah!

Perhatikan bahwa orang yang mengalami kesulitan dengan komentar multiline muncul dua kali di milis dalam beberapa hari terakhir. Yang lebih buruk adalah bahwa beberapa orang mulai mendefinisikan makro atau menggunakan quote untuk meniru ini, yang tampaknya seperti sebuah keburukan yang harus kita hentikan.

Jelas, editor belum cukup baik. Atau pengguna tidak cukup pandai memilih / menggunakan editor mereka, yang merupakan masalah yang lebih sulit dipecahkan.

Konsensus tampaknya menjadi #? ... ?# untuk beberapa pilihan ? . Baik | atau = tampaknya masuk akal untuk ? . Preferensi saya adalah ? menjadi bentuk braket, misalnya #{ ... }# (anggukan untuk Pascal), untuk memanfaatkan pencocokan editor

(Daya tarik komentar multline bukanlah masalah besar bagi saya. Bahkan, saya akan menyebut komentar multiline yang tidak menarik sebagai fitur, bukan bug: ini adalah sesuatu yang harus digunakan untuk peretasan debugging cepat, sedangkan untuk dokumentasi permanen saya masih lebih suka untuk dorong awalan # pada setiap baris untuk membedakan komentar dari kode secara visual.)

Banyak masalah ambiguitas yang dibahas di atas berkaitan dengan membedakan antara operator komentar multiline yang diusulkan, misalnya

#{ ...code commented out... }#

dan kombinasi dari komentar satu baris dengan kode yang valid

#{ ...array at end of line, commented out... }# documentation comment .

Mungkin sudah terlambat, tetapi bagaimana jika komentar satu baris _ diperlukan_ untuk meninggalkan spasi (atau lebih) setelah karakter # ? Ini tentu tidak buruk untuk keterbacaan :-)

Saya sebenarnya telah menggunakan makro @# seperti yang disarankan oleh @kkylin , dan saya merasa senang memperluas ini ke jenis makro "berkomentar" lain juga: misalnya, saya baru-baru ini menulis sepasang makro untuk debugging, di mana seseorang membungkus blok kode, dan di dalamnya yang lain secara efektif mengomentari ekspresi argumennya kecuali ketika blok yang dibungkus melontarkan kesalahan (terutama berguna untuk debugging loop, meskipun milikku belum sepenuhnya kuat).

Satu-satunya batasan signifikan dari pendekatan makro adalah mengomentari bentuk arbitrer dalam ekspresi, yang menyarankan makro baca.

Clojure hanya menggunakan sistem seperti itu sebagai standar:

• komentar satu baris / sisa baris dengan satu karakter ( ; )
• komentar ekspresi-utuh dengan makro ( comment , yang dievaluasi menjadi nil)
• komentar berbentuk arbitrer dengan makro baca ( #_ , yang menghilang secara efektif, sering digunakan dengan "..." menyertakan kode yang diberi komentar)

Sistem ini bersama-sama tampaknya menyediakan dukungan mudah untuk semua kasus penggunaan yang dijelaskan di utas ini (termasuk komentar sebaris), dengan ekstensibilitas untuk pengguna yang mahir.

Masalah https://github.com/JuliaLang/julia/issues/455#issuecomment -4178835 meningkatkan masalah penyorotan sintaks terhadap makro baca, tetapi setidaknya satu editor Clojure tampaknya mendukung penyorotan sintaks untuk #_ membaca makro [1]. Saya belum menggunakannya, tapi mungkin ini kasus khusus?

[1] http://code.google.com/p/counterclockwise/issues/detail?id=109#c2

Julia tidak memiliki makro baca, tetapi Anda dapat mengomentari teks arbitrer dengan literal string non-standar:

macro comment_mstr(x) end

comment"""
Not parsed or interpolated.
"""

Saya tidak sepenuhnya yakin ini perlu di Base.

Pilihan lain yang tidak terlalu serius: → dan ←.

Kasus penggunaan yang paling penting, IMO, bukanlah komentar multiline tetapi _inline_ comments. Penggunaan tanda kutip dan makro tidak berfungsi dengan baik untuk kasus ini. Saya masih mendukung #= ... =# tetapi seseorang harus menerapkannya.

Anda dapat mengomentari teks arbitrer dengan literal string non-standar

Perbedaannya adalah bahwa makro kosong bernilai nothing , sehingga tidak memenuhi banyak kasus penggunaan, misalnya:

(x, comment"y," z) => kesalahan

foo() = option(1) comment"option(2)" => kesalahan

begin
foo()
comment"optional()"
end

=> tidak ada

Hal yang sama juga terjadi pada makro comment di Clojure, yang merupakan alasan makro baca.

Saya suka @ #, tapi mungkin lebih banyak mengetik daripada yang disukai orang.

Satu sen saya adalah itu

#

multiline
komentar

#

Akan berdampak buruk bagi saya, dan mungkin orang lain. Saya dengan sembrono menggunakan #, ##, ###, atau sejumlah #s saat mengomentari sesuatu, berdasarkan seberapa bagus tampilannya. ## cukup populer. Saya pikir itu mungkin menyebabkan perilaku aneh jika hal semacam ini biasa terjadi.

Hanya ingin menyatakan bahwa saya juga sangat menyukai #= ... =# dan untuk mengomentari blok kode yang lebih besar ini akan sangat berguna. Sayangnya cadel saya tidak ada sehingga saya tidak dapat membantu penerapannya.

Seperti yang disebutkan di # 6132 dan # 6444, sintaks #= .... =# terbukti agak mengganggu dalam praktiknya karena # dapat memulai baik komentar baris tunggal atau komentar multi-baris.

Bagaimana kalau %= ... =% sebagai gantinya? Ada beberapa preseden untuk % sebagai karakter komentar (Matlab), % tidak pernah digunakan sebelum atau setelah = dalam kode Julia yang valid saat ini, dan statistik di # 6128 menyarankan bahwa % jarang digunakan dalam kode Julia.

Secara teknis %= adalah operator.
Masuk akal bagi saya untuk menggunakan # karena sudah dikaitkan dengan komentar.

Bagaimana dengan menggunakan #=# yang kemungkinan akan dihapus? Ini membuat komentar multilini lebih memberatkan untuk digunakan, tetapi secara substansial akan menurunkan kemungkinan Anda membuat komentar multilini secara tidak sengaja.

Komentar multiline umumnya berpasangan dan tidak ada pasangan untuk #=# .

Saya kira tidak ada yang akan mengakui penggunaan #=#= saat komentar dimulai.

Urutan mulai komentar multiline saat ini merusak banyak kode yang saya tulis yang terlihat seperti:

#=============
# Comment
#=============

Karena saya telah menggunakan banyak blok komentar serupa lainnya dengan #--- atau #### , saya harap kami tidak memojokkannya di masa mendatang.

Oke, nix di %= .. =% lalu. Saya kehabisan ide yang waras.

@johnmyleswhite menurut Anda #___ dan ___# juga akan merusak pola pemformatan umum?

Jelas terlihat jarang bahwa garis bawah tiga akan muncul sebagai prefiks nama variabel (tidak muncul di basis, seperti yang dilakukan garis bawah tunggal dan ganda).

Relatif sulit untuk menghitung garis bawah secara visual untuk membedakan #__ dari #___ , setidaknya dalam font saya. Kemungkinan lain yang disebutkan di # 6128 adalah #% ... %# , yang agak jelek dan tidak ada yang benar-benar menyukainya tetapi tampaknya relatif tidak mungkin bertabrakan dengan komentar satu baris (mungkin justru karena itu jelek, dikombinasikan dengan fakta bahwa % jarang digunakan).

Atau kita bisa tetap menggunakan #= ... =# asli Stefan. Tampaknya layak untuk dikunjungi kembali sekarang karena orang memiliki kesempatan untuk mencobanya, sebelum dipasang di batu (yah, setidaknya di tanah liat) oleh rilis 0,3.

Saya pikir tetap menggunakan #= adalah ide yang bagus, dan pengguna hanya perlu tidak memiliki kode seperti @johnmyleswhite di atas. Kita hanya perlu menghindari sintaksis yang dapat menyebabkan komentar naif membuat komentar blok, (misalnya #{ bisa muncul karena Any dict didefinisikan di awal baris) dan #= tampaknya cukup berhasil bagi saya.

Sangat sulit untuk menghitung garis bawah untuk membedakan #__ dari #___ .

Tidak terlalu sulit jika Anda yang mengetiknya (Anda dapat merasakan dan melihatnya muncul), dan tidak ada pembaca yang secara praktis perlu membedakan keduanya.

Jika Anda menyerah pada arah yang jelas secara visual, saya tidak melihat alasan yang baik untuk tidak menjadi Lisp-y dan menggunakan #| dan |# --- statistik frekuensi mulai untuk | vs. % dalam basis (https://github.com/JuliaLang/julia/pull/6128#issuecomment-37433857) berbeda terutama hanya karena definisi untuk % ditulis menggunakan rem .

Mungkin OK untuk menggunakan #= selama peringatan dicetak ketika #== ditemukan. Sayang sekali bahwa untuk fitur sekecil itu seperti komentar multiline, beberapa orang terjebak dalam kesalahan aneh saat menggambar header seni ASCII seperti di https://github.com/JuliaLang/julia/issues/69#issuecomment -39747985.

Masalah tajuk juga dapat diselesaikan dengan membutuhkan spasi di sekitar pengenal #= =# .

+1

Ini adalah fitur terburuk yang pernah ada.

Harap pertimbangkan bahwa blok komentar mungkin berharga dalam blok kode:
foo(x,y) = foo1(x) #|foo1 does ... |# + foo2(y) #|foo2 does ... |#

Saya tahu ini terlihat konyol tetapi mungkin berguna. Jika itu masalahnya maka membuatnya menjadi set dua karakter sangat ideal. Tampilan komentar cadel #| Your boxed in comment |# cukup bagus untuk saya. Saya telah memprogram dan berkomentar secara ekstensif dengan Stata yang menggunakan /* ... */ dan saya merasa itu jelek dan tidak intuitif. Mungkin merusak kode saya, tetapi demi keterbacaan, saya berusaha keras di Stata, untuk tidak menggunakan blokir komentar karena menurut saya sangat jelek.

Hanya mencari tentang bagaimana apa yang disebutkan EconometricsBySimulation. Sangat rumit untuk melakukan beberapa pengujian kode tanpa komentar blok.

Lihat # 6128. #= dan =# telah ditambahkan sebagai pembatas komentar blok di v0.3.

Saya pikir saran @simleb sejauh ini adalah yang terbaik dari setiap orang di utas ini.

Saya pikir pasangan # (# comment #) # akan cukup rapi.

Manfaat:

• karakter # membuatnya terlihat seperti komentar
• tanda kurung membuat simbol pembuka dan penutup yang jelas dan ringkas
• karakter # terakhir membuatnya terlihat lebih baik (quasi-symetric) terutama jika ditulis di barisnya sendiri
  karena simbol pembuka dan penutup berbeda, mereka harus mudah diurai dan penyarangan dapat diizinkan
  >

Kapal telah berlayar karena masalah ini - itulah mengapa ditutup.

Entah saya akan gila atau #= =# tidak bekerja di jupyter. Bukannya saya suka menggunakan jupyter, tapi saya tidak bisa menginstal Juno / Sublime saya untuk bekerja - tapi saya ngelantur.

Saat membangun suatu fungsi, apakah ada cara untuk memiliki komentar multiline yang bekerja dengan cara yang sama seperti fungsi bantuan dan mencetak yang diperlukan? Dan jika menggunakan jupyter bagaimana caranya?

Komentar multiline berfungsi di jupyter tetapi penyorotan sintaks tidak.

@Bayu_joo

Persis

saat itu juga

EDIT: semakin saya memikirkannya, semakin tidak perlu hal ini tampaknya. Mengingat ini benar-benar hanya menggunakan penurunan harga. Itu hanya kebiasaan.

Jupyter membutuhkan tambalan ke mode Julia codemirror. (Menurut saya ini bukan prioritas tinggi karena komentar multiline jarang digunakan secara interaktif. Kebanyakan komentar tersebut digunakan untuk mengomentari blok besar dalam sebuah file.) Cc @malmaud

Benar. Saya tidak berpikir ini adalah sesuatu yang bisa saya lakukan untuk sementara waktu.

Bagaimana cara kerja baris bersarang dan komentar multibaris? Saat ini (0.5.0) kode berikut ini valid:

##=

Namun, "membungkusnya" di dalam komentar beberapa baris menghasilkan kode yang tidak valid:

`# =

=

= # `

Apakah ini benar-benar perilaku yang diinginkan?

Mungkin #= ##= =# seharusnya valid; harus menjadi patch parser langsung. Bisakah Anda mengajukan masalah?

Komentar multiline adalah hal favorit kami untuk dikerjakan di parser, dan fitur utama Julia secara keseluruhan, jadi saya yakin @JeffBezanson akan

Oh, saya bisa saja mengajukan masalah, tetapi saya bahkan tidak yakin bahwa kode itu seharusnya valid sejak awal.
Saya hanya ingin tahu dan mencoba mencari tahu apakah mungkin untuk mengumpulkan komentar dari berbagai jenis.

Secara khusus: Haruskah komentar baris menjadi komentar baris dalam komentar beberapa baris? Dan haruskah komentar multi-baris menjadi komentar multi-baris dalam baris-komentar? Perasaan pribadi saya akan menjawab "tidak" dalam kedua kasus karena jika tidak, Anda kemungkinan besar akan mengalami masalah "rentang tumpang tindih" yang tentunya merupakan Hal Buruk (perbaiki saya jika saya salah - mungkin ada cara untuk mencegahnya).

Dalam hal ini, hash kedua dalam kode tidak akan memulai komentar baris tetapi hanya beberapa karakter tanpa arti khusus sedangkan #= akan membuka komentar multi-baris bersarang (BTW, nama itu sangat disayangkan karena komentar multi-baris jelas tidak diperlukan untuk menjangkau banyak baris; IMHO "blokir komentar" akan menjadi pilihan yang lebih baik) yang akan ditutup oleh penghentian =# , sehingga meninggalkan multi-baris "luar" komentar tidak ditutup. Jadi, Julia akan sangat tepat menolak kode tersebut.

Jadi, saya ulangi pertanyaan saya: Apakah ada "pendapat resmi" tentang cara menangani komentar bertingkat dari berbagai jenis?

#= dimaksudkan untuk membuka komentar yang mungkin, tetapi tidak perlu, menjangkau lebih dari satu baris.
=# dimaksudkan untuk menutup komentar yang dibuka dengan #=
#= dan =# dipasangkan, dan pasangan dapat disatukan
[membiarkan satu =# menutup semua blok komentar terbuka bertingkat yang sewenang-wenang telah dipertimbangkan dan disisihkan]

#= .. =# harus berperilaku sama apakah ada karakter komentar sebaris # muncul sebelum, antara, setelah .. atau di riff dispersional lainnya (seingat saya) .

ini harus diurai sebagai komentar,
sekarang tidak
(jika Anda PR, harap sertakan ini)

   #=# comment #=#

Sigh, bisakah kita menghapus fitur ini?

Selama 2 ½ tahun saya di Julia, pada dasarnya saya tidak pernah melihat keluhan tentang ini. Lupakan saja itu ada?

Saya akan tetapi orang-orang terus mengomentari masalah ini.

Komentar multiline umumnya berguna. Karena sintaksnya tidak
sudah mendarah daging, masih mudah untuk menolaknya demi sesuatu yang lebih baik.
Pada hari Jumat, 10 Maret 2017 pukul 10.25 Stefan Karpinski [email protected]
menulis:

Saya akan tetapi orang-orang terus mengomentari masalah ini.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/JuliaLang/julia/issues/69#issuecomment-285697167 , atau nonaktifkan
utasnya
https://github.com/notifications/unsubscribe-auth/AA8SvRthejzfJrysM9UaBlX437A65el7ks5rkWt-gaJpZM4AF2X9
.

Saya menggunakan komentar multiline dan menganggapnya sangat berguna.

@StefanKarpinski Kami membutuhkan penjelasan interspersable. Permadani adalah kode.

Octothorpe kita lebih dari octo daripada thorpe, three of a kind daripada one kind of three.

# tetap menjadi tanda di mana# -mengikuti] melalui eol.

Untuk komentar dan isolasi kode sementara, konteks komentar yang dikelilingi pasangan mengabaikan # s dan eols. Urutan konteks komentar ini, bersarang dan melepas seperti tanda kurung. Saya pikir hanya ada satu alternatif ASCII yang bebas konflik dan mudah dilihat.

[=

function ab(a, b)
    return a^b / b^a
end

=]