Mengapa pemformatan kode kaya tidak lebih umum?


29

Saya membaca Kode Lengkap dan dalam bab tentang tata letak dan gaya, dia memperkirakan bahwa editor kode akan menggunakan semacam format teks kaya. Itu artinya, bukannya kode yang terlihat seperti ini

Procedure ResolveCollisions
{ Performs a posteriori collision resolution through spatial partitioning algoritm }
(
  CurrentMap : SpriteContext,
  PotentialColliders: SpriteList
)
var Collider  : Sprite, 
    Collidee  : Sprite, 
    Collision : SpriteCollision
begin
  DoStuff();
end.

itu bisa terlihat seperti ini:

Prosedur ResolveCollisions

Melakukan resolusi tabrakan posteriori melalui algoritma partisi spasial

Parameter

  • CurrentMap : SpriteContext
  • PotentialColliders : SpriteList

Variabel Lokal

  • Collider : Sprite
  • Collidee : Sprite
  • Collision : SpriteCollision
    DoStuff();

Saya telah melihat pewarnaan sintaks dan penyorotan dan bahkan kurung, tetapi tidak ada yang tampak seperti ini dalam kode aktual. Saya bertanya-tanya apakah hal semacam ini benar-benar pernah ada, atau mungkin jika diputuskan bahwa itu tidak memiliki manfaat yang cukup atau bahwa itu adalah ide yang sepenuhnya buruk.

Pernahkah Anda melihat kode berformat kaya seperti ini sebelumnya, atau tahu apakah ide itu pernah dipertimbangkan dan akhirnya ditolak?


8
Pernahkah Anda melihat cweb Knuth? www-cs-staff.stanford.edu/~uno/cweb.html
greyfade



12
Jadi sekarang Anda ingin Word sebagai editor IDE Anda?

5
Anda tidak pernah berkelahi dengan Word ketika melakukan format aneh yang tidak mungkin untuk dihilangkan. Anda misalnya mengandaikan bahwa editor menyembunyikan beberapa bagian dari kode sumber yang sebenarnya. Sebagai pemirsa, tentu akan menyenangkan, saya pikir, sebagai editor, tolong .. kasihanilah jiwa saya yang malang!
Newtopian

Jawaban:


38

Tidak ada alasan teknis yang membuat Anda tidak bisa. Jika editor teks dapat melakukan penyorotan sintaks, mereka dapat dengan mudah mengubah aspek lain dari tampilan untuk menyoroti kode.

Namun, satu hal untuk memiliki apa pun yang sedang diketik berubah warna saat editor mengetahui apa yang Anda ketikkan. Memiliki teks yang tiba-tiba berubah ukuran dan melompat-lompat saat Anda mengetik akan sangat menjengkelkan.

Namun, untuk tampilan kode 'statis', Anda dapat dengan mudah mempercantik kode sumber. Misalnya, ambil setengah dari sumber yang layak-> html converter, dan tambahkan ukuran font dan gaya apa pun yang Anda suka ke stylesheet, dan Anda akan memiliki kode yang diformat kaya.


14

Alasan sederhana: independensi editor / alat.

Setelah Anda membuat kode "kaya" - itu akan dikaitkan dengan editor yang Anda gunakan - atau yang dapat memahami kode kaya. Semua editor lain yang tidak bisa menangani kekayaan akan menunjukkan omong kosong.

Dalam nada yang sama, kode kaya tidak akan cocok dengan alat bantu diff. Misalnya, jika Anda baru saja mengubah beberapa pemformatan, diff akan menunjukkan perbedaan, tetapi bahkan bukan perbedaan yang paling tidak Anda pedulikan.

Dan bagaimana dengan kontrol versi? Bagaimana Anda mengatakannya untuk mengabaikan semua perubahan dalam format dan melihat file yang dimodifikasi hanya ketika ada beberapa perubahan "nyata".

Akhirnya saya kira, inti dari kode kaya adalah keterbacaan - dan untuk itu, saya pikir lebih baik (dan lebih banyak) komentar, nama pengidentifikasi logis, dan lekukan yang konsisten akan cukup.

Intinya, teks pemrograman paling baik ditangani sebagai teks biasa - apa yang Anda lihat adalah apa kenyataannya. ( yang juga sejalan dengan ide Pythonic eksplisit lebih baik daripada implisit )


28
Itu belum tentu benar. Jika editor dapat melakukan penyorotan sintaksis, itu pasti dapat melakukan sintaksis "huruf tebal" atau sintaksis "ukuran huruf", dll.
whatsisname

4
Emacs dapat dikonfigurasi untuk melakukan ini, tetapi IMO mengubah ukuran font akan menjadi pemborosan ruang layar.
kevin cline

4
Jika penulis harus melakukan pemformatan secara manual, itu akan membuang-buang waktu. Jelas, editor teks akan secara otomatis melakukannya, atau mungkin Anda bisa menggunakan semacam stylesheet.
Peter Olson

7
@greegit: editor tidak meninggalkan informasi warna dalam file sumber ketika selesai dengan mereka, mereka tidak harus meninggalkan tanda pemformatan lainnya, mereka dapat membuat ulang sesuai permintaan. Tidak ada perbedaan mendasar antara penyorotan sintaksis dan pemformatan sintaksis. Jika alat dapat membuat diagram kelas yang rumit dan diagram UML dari kode sumber secara otomatis, sebuah alat pasti dapat membuat cetakan tebal dari waktu ke waktu.
whatsisname

9
Jawaban ini tentu memiliki banyak kesalahan karena salah.
Jordan

11

Mungkin kode berformat kaya belum tertangkap karena itu bukan ide yang keren. Secara pribadi, saya tidak suka apa yang saya lihat dalam contoh yang Anda berikan. Saya menggunakan pewarnaan dan penyorotan sintaksis, tetapi pemformatan itu terlalu tempa, dan terlalu menyimpang dari cara saya terbiasa melihat dan menulis kode.


11

Mengapa itu tidak ada? Tidak ada permintaan / kebutuhan untuk itu.

Editor saat ini dapat memenuhi kebutuhan pemrogram dengan penyorotan sintaksis dan beberapa pilihan gaya minor lainnya. Apakah itu belum "teks kaya"?


7
+1 Tanpa permintaan. Saya akan benci kode seperti itu. Sepertinya saya mengetik laporan TPS di Word, bukan menulis kode.

1
@ Allen Nelson: Saya setuju. Saya menghindari Word bahkan untuk mengetik dokumen normal jika saya bisa (saya menggunakan LaTeX sebagai gantinya). Saya suka menyoroti sintaksis tetapi pemformatan kode kaya benar-benar akan terasa mengganggu bagi saya.
Giorgio

5

Ini sudah ada untuk LaTeX dalam mode AucTeX untuk Emacs. Judul bagian lebih besar dalam ukuran, sub dan superskrip diubah ukurannya dengan tepat dan Anda bahkan dapat memiliki sedikit preview matematika (dan mungkin lingkungan lain seperti Algoritma).

Ini bagus untuk LaTeX karena pemetaan dari kode ke output biasanya jauh lebih mudah daripada di program lain; Saya pikir saya tidak akan menyukainya sama sekali untuk bahasa yang lebih umum.

Hal lain yang dapat dilakukan Emacs adalah mengganti simbol seperti ->dan foralldengan dan masing - masing di Haskell. Ada sedikit alasan hal semacam ini tidak dapat diperpanjang untuk melakukan format seperti yang Anda sarankan kecuali bahwa itu tidak perlu sama sekali di Haskell.


2

Beberapa waktu lalu, saya menanyakan pertanyaan ini pada pemformatan kode, menanyakan apakah pemrogram ingin kode mereka diformat saat mereka mengetik.

Pertanyaan saya hanya membahas aspek lekukan pemformatan, tetapi beberapa jawaban mungkin berlaku untuk pemformatan kode secara umum. Sentimen keseluruhan dalam jawaban menunjukkan bahwa programmer menentang kehilangan kendali absolut dari cara kode mereka diwakili.

Pengalaman pribadi saya sangat berbeda. Meskipun saya biasanya menggunakan alat yang tersedia untuk umum, kadang-kadang saya perlu menulis XSLT di editor saya sendiri. Editor ini memformat kode ketika saya mengetik dengan memasukkan margin kiri sehingga saya tidak memiliki masalah dengan spasi yang tidak diinginkan (signifikan dalam XSLT) dan memungkinkan kode saya untuk bungkus kata dan masih mempertahankan format. Saya menemukan pengalaman yang cukup alami, gaya pemformatan dikendalikan oleh konteks dan posisi umpan baris saja (pengalaman ini sangat bermanfaat ketika menggunakan perangkat input sentuh-sensitif).

Jika XSLT tidak seimbang, format sebenarnya membantu menunjukkan di mana masalahnya. Butuh beberapa saat untuk menyesuaikan dengan pemindahan kode secara horizontal saat Anda mengetik, tetapi itu tidak mengganggu saya lagi. Namun saya menemukan bahwa fitur pemformatan yang memengaruhi jarak vertikal XSLT saya membuat editor hampir tidak dapat digunakan, jadi saya telah menonaktifkannya.

Untuk kembali ke pertanyaan Anda, saya pikir alasan mengapa pemformatan kode kaya tidak lebih umum adalah hanya karena butuh waktu lama bagi persepsi untuk berubah di dunia pemrograman. Waktunya akan tiba, mungkin bertepatan dengan waktu ketika mengedit kode dilakukan terutama tanpa keyboard.


2

Juga dalam lebih dari beberapa bahasa (Haskell, Ruby, Python, Erlang, CoffeeScript dan lainnya) lekukan itu penting. Jadi jika Anda mengubah ukuran font itu bisa sangat sulit untuk diketahui.

Sebagian besar tradisinya. Saya telah pemrograman secara profesional selama hampir 20 tahun dan saya curiga ini akan membuat saya gila. Saya menulis buku dalam Emacs atau VI dengan buku catatan, jadi saya bukan penggemar WYSIWIG


2

Knuth's CWEB melakukan ini, tetapi ini hanya berfungsi untuk C / C ++ dan Pascal. - Anda harus melihatnya ... cukup rapi. Ada dua program: ctangledan cweaveyang menggabungkan / memisahkan file CWEB ke dalam TeX dan C masing-masing.


1
nowebbekerja dengan hampir semua bahasa yang memungkinkan. Dan ada banyak sistem pemrograman melek khusus yang tersedia untuk banyak bahasa lain juga (lhs dan sama). Beberapa bahasa memiliki kemampuan pengaturan huruf di luar kotak sejak awal 1960-an - lihat en.wikipedia.org/wiki/Stropping_(programming)
SK-logic

3
@ SK-logic - Arrgh, tolong jangan ingatkan saya tentang kengerian pemrograman terpelajar . Mengubah setiap tinjauan kode cepat menjadi tinjauan dokumen yang membosankan dan panjang , mengkritik setiap pergantian kalimat terakhir dan koma salah tempat. Mengapa beberapa bagian industri pertahanan berpikir ini adalah ide bagus yang tidak akan pernah saya ketahui. Saya tidak berpikir bahwa editor WYSIWYG akan membuatnya lebih baik.
Mark Booth

@Mark Booth, apa pun bisa berubah menjadi horor jika melakukan kesalahan. Pemrograman melek huruf adalah alat yang hebat jika dikombinasikan dengan disiplin yang tepat. Saya tidak tahu bagaimana saya bisa membuat anotasi kode saya dengan rumus, plot, dan grafik TeX-format yang kompleks tanpa alat pemrograman terpelajar. Dan kode tidak akan lagi dapat dibaca dan dipelihara tanpa penjelasan seperti itu.
SK-logic

2

Pernahkah Anda melihat kode berformat kaya seperti ini sebelumnya, atau tahu apakah ide itu pernah dipertimbangkan dan akhirnya ditolak?

Yakin. Xcode mendukung gaya selain pewarnaan sederhana untuk sintaks yang berbeda:

kode sumber dengan teks gaya

Sudah lama sejak saya menggunakannya, tapi saya pikir Metrowerks CodeWarrior mendukung teks gaya juga, dan itu 10+ tahun yang lalu.

Namun, Anda tidak ingin berlebihan dengan style - teks apa pun, kode sumber atau yang lain, bisa lebih sulit dibaca ketika style terlalu beragam. Secara khusus, saya pikir mencampur ukuran mengganggu, dan apa pun yang menyebabkan kolom tidak sejajar mengganggu. Ada alasan sebagian besar programmer masih menggunakan font monospace.

Pertanyaan yang berbeda adalah apakah teks gaya harus digunakan sebagai bagian dari sintaks bahasa itu sendiri. Sebagai contoh, haruskah kompiler menggunakan fakta bahwa beberapa teks ditata dengan cara tertentu untuk menentukan bahwa teks adalah deklarasi fungsi? Awalnya mungkin terdengar gila, tetapi bahasa-bahasa seperti Python dan Fortran sudah menggunakan lekukan sebagai sintaksis. Namun demikian, saya pikir itu lebih mungkin bahwa kita akan terus melihat gaya didorong oleh sintaks daripada sebaliknya. Ada banyak manfaat yang datang dari kemampuan menggunakan teks biasa (kompiler yang lebih sederhana, kemandirian platform, preferensi programmer), dan tradisi lain telah berevolusi untuk membuat kode dapat dibaca tanpa adanya gaya (lekukan, garis kosong, karakter marker, dan fitur editor seperti kode lipat dan menu navigasi).


1

Saya pikir pemformatan kode sumber yang kaya tidak begitu populer karena ditujukan untuk input informasi, di mana struktur dan makna jauh lebih penting (dan lebih mudah untuk diketik juga). Fontification, simbol-simbol khusus ekstra dan spasi putih hanya menambah kebisingan visual yang tidak perlu. Mungkin cocok untuk dokumentasi yang dihasilkan.

Tidak pernah berakhir perang api tentang topik yang sama di dunia penyusunan huruf antara mereka yang lebih memilih editor WYSIWYG (seperti MS Word) dan sistem seperti TeX (LaTeX).

Secara umum, tidak ada jawaban pasti. Itu semua tergantung pada alat, kasus penggunaan dan preferensi pribadi.


1

Alat-alat seperti Doxygen atau JavaDoc sudah memiliki format kode teks kaya perfom. Mereka menambahkan kode hypertext juga untuk tujuan browsing. Anda tidak perlu memasukkan tag khusus untuk pemformatan dasar.

Ini bukan WYSIWYG.


0

Saya takut mengatakan bahwa ini memang ada.

Di masa lalu saya telah bekerja pada beberapa Centura (juga dikenal sebagai Gupta atau SQL / Windows - kode " 4GL "). Itu tidak benar-benar mungkin untuk mengedit kode Centura dalam editor standar seperti notepad lakukan ke tingkat ekstrim format yang diperlukan.

Walaupun mungkin sepertinya ide yang baik untuk memiliki file sumber diformat seperti ini, saya menemukan pengembangan menjadi sangat terbatas dan menyakitkan.

Selain itu, pemformatan sering menyebabkan masalah saat menggabungkan kontrol sumber.


0

Selain jawaban lain, saya ingin menunjukkan bahwa selain kesulitan teknis menggunakan pemformatan kaya, itu juga objek preferensi pribadi.

Jika Anda mengedit teks biasa, Anda dapat memilih font dan warna yang Anda suka, dan mereka diatur secara otomatis. Jika Anda ingin mengedit teks kaya, bagaimana jika Anda tidak suka warna dan font tertentu yang ditetapkan secara manual?


1
Saya pikir ini tidak benar. Saya cukup yakin jika pemrogram menggunakan teks kaya, akan ada generator yang membuat semacam markup semantik yang menggambarkan struktur program, dan kemudian stylesheet yang dapat disesuaikan pengguna yang berisi informasi font dan warna.
Peter Olson

@PeterOlson maka Anda tidak akan dapat membaca program tanpa stylesheet Anda, karena Anda tidak akan mengenali penunjukan string teks. Ini berarti tidak ada yang bisa menunjukkan atau menulis apa pun saat bertemu langsung. Sebaliknya, saat ini font dan warna sepenuhnya opsional dan dapat dipertukarkan tanpa merusak makna.
corvinus

0

Saya pikir ini karena belum ada yang memisahkan pembacaan kode dan penulisan kode. Setidaknya itu tidak menjadi mainstream. Terkadang Anda harus membaca kode yang Anda sentuh dulu atau kode yang dibuat oleh pengembang lain. Anda mungkin harus menghabiskan banyak waktu hingga siap untuk mengubah satu byte di sumber ini. Ini bisa berupa mode "baca" yang dapat melakukan apa pun yang diperlukan untuk memudahkan pemahaman (ukuran font, format ulang, sub-skrip, skrip super, dll). Saat Anda siap, editor dapat beralih ke mode "tulis" dan tidak terlalu membatasi dan lebih mematuhi "aturan yang paling tidak mengejutkan"

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.