Bagaimana editor kode secara efektif memberi petunjuk pada level kode bersarang - tanpa menggunakan indentasi? [Tutup]

Saya telah menulis editor teks XML yang menyediakan 2 opsi tampilan untuk teks XML yang sama, satu indentasi (secara virtual), yang lain dibenarkan kiri. Motivasi untuk tampilan yang dibenarkan kiri adalah untuk membantu pengguna 'melihat' karakter spasi putih yang mereka gunakan untuk lekukan teks biasa atau kode XPath tanpa gangguan dari lekukan yang merupakan efek samping otomatis dari konteks XML.

Saya ingin memberikan petunjuk visual (di bagian editor yang tidak dapat diedit) untuk mode yang dibenarkan kiri yang akan membantu pengguna, tetapi tanpa terlalu rumit.

Saya mencoba hanya menggunakan jalur penghubung, tapi itu sepertinya terlalu sibuk. Sejauh ini yang terbaik yang saya hasilkan ditunjukkan dalam screenshot tiruan editor di bawah ini, tetapi saya mencari alternatif yang lebih baik / lebih sederhana (yang tidak memerlukan terlalu banyak kode).

[Sunting]

Mengambil ide heatmap (dari: @imp) saya mendapatkan ini dan 3 alternatif - berlabel a, b dan c:

Bagian berikut menjelaskan jawaban yang diterima sebagai proposal, menyatukan ide-ide dari sejumlah jawaban dan komentar lainnya. Karena pertanyaan ini sekarang adalah wiki komunitas, silakan perbarui ini.

NestView

Nama untuk gagasan ini yang menyediakan metode visual untuk meningkatkan keterbacaan kode bersarang tanpa menggunakan lekukan.

Garis Kontur

Nama untuk garis yang diarsir berbeda dalam NestView

Gambar di atas menunjukkan NestView yang digunakan untuk membantu memvisualisasikan cuplikan XML. Meskipun XML digunakan untuk ilustrasi ini, setiap sintaks kode lain yang menggunakan nesting dapat digunakan untuk ilustrasi ini.

Gambaran:

1. Garis kontur diarsir (seperti dalam peta panas) untuk menyampaikan tingkat bersarang

2. Garis kontur miring untuk menunjukkan kapan level bersarang dibuka atau ditutup.

3. Garis kontur menautkan mulai dari level bersarang ke ujung yang sesuai.

4. Lebar garis kontur yang digabungkan memberikan kesan visual tingkat bersarang, di samping peta panas.

5. Lebar NestView mungkin dapat diubah ukurannya secara manual, tetapi tidak boleh berubah karena kode berubah. Garis kontur dapat dikompres atau dipotong untuk mempertahankannya.

6. Baris kosong terkadang menggunakan kode untuk memecah teks menjadi potongan-potongan yang lebih mudah dicerna. Baris seperti itu dapat memicu perilaku khusus di NestView. Misalnya peta panas dapat diatur ulang atau garis kontur warna latar belakang digunakan, atau keduanya.

7. Satu atau lebih garis kontur yang terkait dengan kode yang dipilih saat ini dapat disorot. Garis kontur yang terkait dengan tingkat kode yang dipilih akan paling ditekankan, tetapi garis kontur lain juga bisa 'menyala' di samping untuk membantu menyoroti grup bertingkat yang mengandung

8. Perilaku yang berbeda (seperti pelipatan kode atau pemilihan kode) dapat dikaitkan dengan mengklik / mengklik dua kali pada Garis Kontur.

9. Bagian garis kontur yang berbeda (ujung depan, tengah, atau belakang) mungkin memiliki perilaku dinamis yang berbeda.

10. Tooltips dapat ditampilkan pada acara mouse di atas garis kontur

11. NestView diperbarui terus-menerus saat kode diedit. Di mana asumsi bersarang tidak seimbang dapat dibuat di mana level bersarang harus berakhir, tetapi garis kontur sementara yang terkait harus disoroti dalam beberapa cara sebagai peringatan.

12. Perilaku seret dan lepas dari Garis Kontur dapat didukung. Perilaku dapat bervariasi sesuai dengan bagian garis kontur yang diseret.

13. Fitur yang biasa ditemukan di margin kiri seperti penomoran baris dan penyorotan warna untuk kesalahan dan perubahan kondisi dapat menutupi NestView.

Fungsi Tambahan

Proposal membahas berbagai masalah tambahan - banyak di luar ruang lingkup dari pertanyaan awal, tetapi efek samping yang bermanfaat.

Menautkan secara visual awal dan akhir wilayah bersarang

Garis kontur menghubungkan awal dan akhir setiap tingkat bersarang

Sorot konteks dari baris yang dipilih saat ini

Saat kode dipilih, level sarang terkait di NestView dapat disorot

Membedakan antara wilayah kode pada tingkat bersarang yang sama

Dalam kasus XML, warna yang berbeda dapat digunakan untuk ruang nama yang berbeda. Bahasa pemrograman (seperti c #) mendukung daerah bernama yang dapat digunakan dengan cara yang sama.

Membagi area dalam area bersarang menjadi blok visual yang berbeda

Garis ekstra sering dimasukkan ke dalam kode untuk membantu keterbacaan. Baris kosong seperti itu dapat digunakan untuk mereset level saturasi garis kontur NestView.

Tampilan Kode Multi-Kolom

Kode tanpa lekukan membuat penggunaan tampilan multi-kolom lebih efektif karena pembungkus kata atau pengguliran horizontal cenderung tidak diperlukan. Dalam tampilan ini, setelah kode mencapai bagian bawah satu kolom, kode akan mengalir ke yang berikutnya:

Penggunaan lebih dari sekadar memberikan bantuan visual

Seperti yang diusulkan dalam ikhtisar, NestView dapat menyediakan serangkaian fitur pengeditan dan seleksi yang akan secara luas sejalan dengan apa yang diharapkan dari kontrol TreeView. Perbedaan utama adalah bahwa simpul TreeView khas memiliki 2 bagian: ikon expander dan ikon node. Garis kontur NestView dapat terdiri dari 3 bagian: pembuka (miring), konektor (vertikal) dan tutup (miring).

Pada Indentasi

NestView disajikan bersama pelengkap kode tanpa lekukan, tetapi tidak mungkin untuk menggantikan, tampilan kode lekukan konvensional.

Kemungkinan setiap solusi yang mengadopsi NestView, akan menyediakan metode untuk beralih secara mulus antara tampilan kode indentasi dan non-indentasi tanpa mempengaruhi teks kode itu sendiri - termasuk karakter spasi putih. Salah satu teknik untuk tampilan lekukan adalah 'Pemformatan Virtual' - di mana margin kiri dinamis digunakan sebagai pengganti karakter tab atau spasi. Data tingkat sarang yang sama yang digunakan untuk secara dinamis membuat NestView juga dapat digunakan untuk tampilan indentasi yang lebih konvensional.

Pencetakan

Lekukan akan menjadi penting untuk keterbacaan kode cetak. Di sini, tidak adanya karakter tab / spasi dan margin kiri dinamis berarti bahwa teks dapat membungkus pada margin kanan dan tetap mempertahankan integritas tampilan indentasi. Nomor baris dapat digunakan sebagai penanda visual yang menunjukkan di mana kode dibungkus dengan kata dan juga posisi indentasi yang tepat:

Layar Real-Estate: Flat Vs Indented

Mengatasi pertanyaan apakah NestView menggunakan real-estate layar yang berharga:

Garis kontur berfungsi dengan baik dengan lebar yang sama dengan lebar karakter editor kode. Oleh karena itu, lebar NestView dengan 12 karakter dapat mengakomodasi 12 level sarang sebelum garis kontur dipotong / dikompresi.

Jika tampilan lekukan menggunakan 3 karakter-lebar untuk setiap level bersarang maka ruang disimpan hingga bersarang mencapai 4 level bersarang, setelah level bersarang ini, tampilan datar memiliki keunggulan hemat-ruang yang meningkat dengan setiap level bersarang.

Catatan: Lekukan minimum 4 lebar karakter sering direkomendasikan untuk kode, namun XML sering kali mengelola dengan kurang. Juga, Pemformatan Virtual memungkinkan lekukan yang lebih sedikit untuk digunakan karena tidak ada risiko masalah penyelarasan

Perbandingan 2 tampilan ditampilkan di bawah ini:

Berdasarkan hal di atas, mungkin adil untuk menyimpulkan bahwa pilihan gaya tampilan akan didasarkan pada faktor-faktor selain layar real-estate. Satu-satunya pengecualian adalah di mana ruang layar berada pada premium, misalnya pada Netbook / Tablet atau ketika beberapa kode jendela terbuka. Dalam kasus ini, NestView yang dapat diubah ukurannya tampaknya menjadi pemenang yang jelas.

Gunakan Kasing

Contoh-contoh dunia nyata di mana NestView mungkin merupakan opsi yang berguna:

1. Di mana layar real-estat berada di premium

   Sebuah. Pada perangkat seperti tablet, notes, dan ponsel cerdas

   b. Saat menampilkan kode di situs web

   c. Ketika beberapa kode windows perlu terlihat di desktop secara bersamaan

2. Dimana lekukan spasi putih yang konsisten dari teks dalam kode adalah prioritas

3. Untuk meninjau kode yang sangat bersarang. Misalnya di mana sub-bahasa (misalnya Linq di C # atau XPath di XSLT) dapat menyebabkan tingkat bersarang yang tinggi.

Aksesibilitas

Pengubahan ukuran dan opsi warna harus disediakan untuk membantu mereka yang memiliki gangguan penglihatan, dan juga agar sesuai dengan kondisi lingkungan dan preferensi pribadi:

Kesesuaian kode yang diedit dengan sistem lain

Sebuah solusi yang menggabungkan opsi NestView idealnya mampu menghilangkan karakter tab dan spasi terkemuka (diidentifikasi sebagai hanya memiliki peran format) dari kode yang diimpor. Kemudian, setelah ditelanjangi, kode tersebut dapat ditampilkan dengan rapi di tampilan kiri-kanan dan lekukan tanpa perubahan. Bagi banyak pengguna yang mengandalkan sistem seperti penggabungan dan alat diff yang tidak sadar spasi ini akan menjadi perhatian utama (jika bukan show-stopper lengkap).

Pekerjaan lain:

Visualisasi Markup yang Tumpang tindih

Penelitian yang diterbitkan oleh Wendell Piez , tertanggal dari 2004, membahas masalah visualisasi markup yang tumpang tindih, khususnya LMNL . Ini termasuk grafik SVG dengan kemiripan yang signifikan dengan proposal NestView, sehingga diakui di sini.

Perbedaan visualnya jelas pada gambar (di bawah), perbedaan fungsional utama adalah bahwa NestView hanya dimaksudkan untuk XML atau kode yang tersusun rapi, sedangkan grafik Wendell Piez dirancang untuk mewakili penyarangan yang tumpang tindih.

Grafik di atas direproduksi - dengan izin baik - dari http://www.piez.org

Sumber:

1. Menuju Markup Hermenutik
2. Setengah langkah menuju LMNL

Saya telah mencoba untuk menjawab pertanyaan saya sendiri di sini, tetapi ini menggabungkan ide peta panas dari @imp dan juga ide 'membuatnya lebih XML-ish' dari @Andrea:

Mudah-mudahan, warna-warna di peta panas bersama dengan garis sudut membantu menarik mata antara tag awal dan akhir; menghapus pemisah garis horizontal meningkatkan 'aliran' dari awal hingga akhir. Saat pengguna memilih dengan elemen bagian yang cocok dalam peta panas dapat disorot dalam beberapa cara - mungkin dengan perbatasan bercahaya (seperti yang ditunjukkan).

Sunting Telah memutuskan untuk mengikuti ini, mungkin harus ada opsi pengguna untuk warna. Tangkapan layar 'siap produksi':

Dan untuk perbandingan ... tampilan indentasi alternatif:

Sunting Sekarang, untuk kasing yang lebih berat - menguji kemampuan menggambar saya ...

Satu ide mungkin untuk mencoba dan menambahkan 3D ke teks. Menambah / mengurangi ukuran font berdasarkan level apa itu.

Misalnya, kode ini:

Akan terlihat seperti ini:

Itu mungkin mengganggu untuk bekerja karena kehilangan penjajaran ukuran teks tetap di berbagai tingkatan. Ide lain; ubah saturasi setiap level:

Seberapa baik itu bertahan untuk sesuatu yang sangat dalam? Tidak yakin...

Saya sebenarnya sangat menyukai ide visualisasi selokan Anda; mudah untuk mengelompokkan berbagai hal bersama. Mungkin dikombinasikan dengan salah satu dari ide-ide ini itu akan terlihat lebih baik, atau jauh lebih jelek. ;)

Beberapa waktu yang lalu saya melakukan peta panas yang menunjukkan ruang lingkup di C. Mungkin menyenangkan untuk melihat untuk brainstorming:

Rata kiri:

Hanya mengubah ide asli Anda dan beralih dari kotak ke kapsul. Saya pikir versi ini (termasuk yang asli Anda) lebih mudah dibaca karena mereka kurang kompleks daripada yang menunjukkan bersarang melalui elemen tampilan bersarang. Saya pikir elemen pohon menyampaikan informasi dengan cara yang lebih sederhana dan lebih intuitif.

Saya pikir sisi kiri bagus untuk menunjukkan indentasi secara langsung, sementara sisi kanan lebih baik dalam menyampaikan hubungan yang bersarang.

Ide saya:

Sarang itu lebih mirip sarang. Lebar horizontal setiap lapisan tidak harus terlalu lebar.

Saya suka ide itu. Saran saya untuk menjaga "sibuk" adalah untuk menggunakan gradien alih-alih kotak. Itu akan memotong garis. Mungkin warna berbeda untuk lekukan ekstrem.

Saya akan mengatakan semua yang Anda miliki bagus, meskipun sedikit kuning untuk selera saya.

Komentar saya: Saya selalu berjuang dengan cara Visual Studio IDE melakukan lekukan. Saya ingin menggunakan sesuatu seperti ini atau variasi.

Jadi bayangkan tautan itu tanpa garis, dan segaris dengan xml / kode Anda saat ini.

Karena Anda mengatakan visualisasi harus ada di margin yang tidak dapat diedit (kiri?), Saya percaya bahwa maksud visualisasi tidak dapat diintegrasikan atau berada di belakang kode.

Mungkin peta panas di kolom kiri, dengan warna-warna cerah yang menunjukkan lekukan yang lebih dalam? Jadikan margin sebagai ukuran tetap, dengan visualisasi seperti apa yang Anda miliki (harapkan dari kiri ke kanan seperti lekukan) yang secara dinamis menggunakan semua ruang yang diberikan sesuai dengan lekukan maksimum yang ditentukan oleh kedalaman DOM.

Jika Anda bersedia untuk bercabang ke wilayah editor, saya akan menyarankan sesuatu yang sangat mirip, tetapi sebagai latar belakang dokumen. Daerah yang diarsir akan di mana spasi akan jika lekukan yang diaktifkan. Dalam hal ini, saya akan menggunakan warna yang terang dan terang yang kontras dengan penyorotan teks.

jGRASP melakukan ini dengan menggunakan penanda visual di margin:

Bahkan mengenali ketika Anda menggunakan loop dan menggunakan jenis garis yang berbeda untuk mewakili loop batin itu.

Saya pikir saya akan menunjukkan bagaimana editor yang ada melakukannya.

Bukan ide yang buruk tetapi harus merujuk margin kiri untuk melihat dengan jelas blok saya mungkin sedikit mengganggu. Itu bahkan tidak memikirkan layar real-estate atau hal-hal apa yang akan mulai terlihat jika struktur menjadi sangat dalam.

Karena motivasinya adalah untuk membantu pengguna 'melihat' karakter spasi putih yang mereka gunakan untuk indentasi, Anda bisa menunjukkan kepada mereka karakter spasi putih.

Saya tidak berbicara karakter visual khusus seperti penanda paragraf, hanya highlight. Spasi berwarna kuning, tab berwarna hijau (atau apa pun)

Untuk masalah margin / nesting, Anda bisa memindahkan margin untuk setiap blok. Tidak ada yang mengatakan margin harus berupa garis lurus.

Saya yakin ini bukan ide baru.

Sesuatu seperti ini:

Mengapa tidak membuka dan menutup tanda kurung?

1. Lekukan berarti penahanan: (dan) berarti persis seperti itu bagi programmer.
2. (dan) masing-masing karakter tunggal: bilah kiri akan tetap sangat tipis.
3. Elemen kosong mudah terlihat: use () pada baris yang sama.
4. Konten suatu elemen tidak memerlukan petunjuk visual: kosong jauh lebih baik.
5. Posisi kursor di sebelah kanan dapat dicocokkan dengan blok yang mengandung di sebelah kiri: secara dinamis menambahkan warna ke karakter di kolom dengan (dan)
6. Anda bisa membuatnya lebih XML-ish menggunakan <dan>, yang terlihat lebih baik dari kejauhan.

Vim sudah bisa melakukan hal serupa, meskipun tidak secantik itu.

Ada berbagai cara melakukan "kode lipat" di Vim. Salah satunya didasarkan pada aturan lipat sintaksis. Ketika ini dilakukan, kode dapat dilipat menggunakan struktur garis bersarang, dan "FoldColumn" dapat digunakan untuk memberikan representasi grafis (sebenarnya "berbasis karakter" dengan karakter '|' dan '-' chars) dari "foldlevel" .

Kolom lipat dapat memberikan representasi sarang terlepas dari metode lipat, tetapi metode berbasis sintaks adalah metode yang mungkin sesuai untuk apa yang Anda inginkan. Saya tidak yakin apakah ada aturan lipat berbasis sintaks pra-dibuat di luar sana untuk xml di suatu tempat, saya kira mungkin ada.

Saya pikir Anda berada di jalur yang benar dengan opsi B dan C: termasuk pewarnaan lebar dan peta panas. Saya suka opsi B lebih dari C pada saat ini, karena itu kurang mengganggu (baik yang lebar dan diencerkan, atau sempit dan intens, daripada blok yang sangat berat di tengah C) Satu kelemahan adalah bahwa dengan opsi itu Anda harus bangun kembali seluruh grafik jika Anda memasukkan level di suatu tempat. Saya pikir Anda bisa membuat blok lebih kecil, 1 atau 2 px mungkin akan cukup. Tidak harus banyak, hanya perlu dibedakan. Terutama ketika orang diharapkan untuk menggunakan editor berkali-kali, efek yang tidak mencolok dan lebih halus lebih mudah untuk dikerjakan karena mereka tidak terlalu mengganggu.

Satu hal yang penting ketika menggunakan semacam editor adalah menyoroti ruang lingkup saat ini: ketika memilih garis di editor, Anda perlu melihat dengan tepat elemen apa yang dikandungnya, dan di mana ia berhenti. Anda bahkan bisa menyorot pohon ke atas (elemen apa itu anak). Saya pikir itu adalah masalah terpisah yang perlu ditangani dan dipikirkan dan akan memiliki lebih banyak pengaruh pada bagaimana pengguna akan menilai pengalaman mereka dengan editor.

Satu hal yang belum saya lihat disebutkan adalah apa yang dapat Anda lakukan dengan rona di atas efek saturasi yang tampaknya telah Anda selesaikan. Saran saya adalah untuk mengubah warna sarang di mana pointer berada. Ini akan membuatnya lebih mudah bagi pengguna untuk membedakan garis mana yang merupakan bagian dari sarang, dibandingkan saudara kandung di sepanjang jalan.

Saat menerapkan hal-hal berbasis rona, harap sadar akan kebutaan warna, dan baik pilih warna yang dapat dibedakan secara universal, atau menawarkan beberapa pilihan bagi orang untuk memilih.

Satu opsi, yang dapat digunakan bersamaan dengan saran lainnya sejauh ini, adalah dengan menggunakan tooltip di margin kiri yang menunjukkan jalur ke garis menggunakan notasi XPath. Alat "periksa elemen" peramban (mis. Firebug, yang ada di dalam Chrome) sering melakukan hal serupa tetapi di bilah status.

Mungkin Anda bisa memiliki tampilan runtuh untuk peta panas (dari pos asli) dengan hanya satu kolom warna dan angka kedalaman. Ini akan memungkinkan mereka untuk mengetahui seberapa dalam mereka dan memberi mereka lebih banyak layar real estat untuk xml. Sepertinya menang untuk saya.

Saya khawatir apakah akan ada perbedaan warna yang cukup untuk membuat sarang dalam-dalam.