Bagaimana perasaan Anda jika editor kode Anda memformat kode Anda saat Anda mengetik, tanpa tab / spasi? [Tutup]

Seperti kebanyakan hal, saya yakin konsep ini telah dicoba sebelumnya - saya hanya belum menemukan editor yang menggunakan apa yang saya sebut 'Pemformatan Virtual'. Prinsipnya adalah bahwa ada margin kiri mengambang yang mensimulasikan efek dari ruang padding / karakter tab yang secara konvensional dimasukkan oleh pengembang atau editor itu sendiri untuk memformat kode. Editor terus mem-parsing kode (bahkan ketika dikomentari) saat Anda mengetik dan menghitung indentasi yang diperlukan berdasarkan konteks di mana setiap umpan baris ditemukan

Saya mengembangkan ide ini bekerja secara khusus dengan editor XML karena XML memiliki beberapa masalah aneh dengan memformat karakter dan cenderung sangat bersarang, namun saya percaya banyak prinsip masih berlaku untuk kode konvensional.

Pernahkah Anda mengalami pengkodean dengan alat seperti itu atau apakah Anda memiliki pandangan apakah itu akan membantu atau menghambat? Apakah itu akan menyebabkan masalah dengan sistem kontrol versi? (Mendeteksi dan menghapus semua karakter padding yang ada)

Kecuali Anda sudah mencobanya, perilaku alat semacam itu sulit untuk dijelaskan, itu terlihat konvensional sampai Anda benar-benar mulai mengedit. Saya telah memasang video screencast yang menunjukkan prototipe beraksi yang menunjukkan pengeditan XML, mengubah hierarki dan melakukan operasi seret / lepas dan salin dan tempel, lalu bagaimana pemformatan rusak / diperbaiki ketika karakter yang tidak valid diketik.

Sunting Semua jawaban / komentar sejauh ini negatif - jadi untuk mencoba memperbaiki keseimbangan, beberapa manfaat pemformatan virtual untuk dipikirkan:

• Tidak ada lagi perdebatan tentang pemformatan standar, cukup tempatkan umpan baris yang sesuai dengan konvensi yang Anda pilih / mandat
• Di mana ruang di premium (dalam buku / blog / dokumentasi) Anda dapat membungkus kata tetapi masih mendapatkan lekukan yang sempurna
• Setiap blok kode dapat memiliki 'pegangan mouse' yang berbatasan langsung dengan tempat dimulainya, tidak diperas ke tepi layar - klik ini untuk memilih seluruh blok atau blok-dalam
• Seret, lepas dan lupakan - menjadi layak untuk pertama kalinya
• Tidak ada waktu yang dihabiskan untuk memformat ulang kode orang lain
• Tidak ada kode yang diformat secara salah (dalam arti tidak ada - hanya rendering)
• Menggunakan Backspace alih-alih Ctrl + Backspace menjaga jari-jari Anda pada tombol panduan keyboard
• Render fleksibel - menyesuaikan pemformatan yang diberikan dengan lingkungan Anda, ada yang mencoba membaca kode pada ponsel / tablet layar kecil?
• Pertimbangkan bahwa ada sekitar 25% lebih sedikit karakter yang dapat diedit (dalam sampel XSLT), bukankah itu memiliki manfaat efisiensi?

Edit - Kesimpulan sejauh ini

1. Pengembang telah menetapkan alat dan metode kerja yang secara efisien mengatasi sebagian besar kerugian yang melekat dalam penggunaan karakter padding yang digunakan untuk indentasi.

2. Ada kekhawatiran bahwa penghapusan karakter pemformatan akan berdampak buruk pada beberapa alat yang berbeda.

3. Pengembang menginginkan fleksibilitas untuk memformat 'fine-tune' sedemikian rupa sehingga rendering otomatis tidak dapat menangani.

4. Penghapusan spasi / tab utama berarti bahwa alat 'sadar kode' yang mampu memformat kode diperlukan untuk meninjau kode tersebut secara efisien - editor teks biasa tidak akan menampilkan pemformatan.

5. Mereka yang merasa mungkin ada beberapa manfaat hipotetis (untuk indentasi virtual), memiliki pandangan bahwa kerugian lebih besar daripada manfaat potensial - secara meyakinkan .

Edit - Putusan

Persepsi tentang hambatan dan sedikit (jika ada) manfaatnya sedemikian rupa sehingga tidak bijaksana bagi saya, sebagai pengembang tunggal, untuk mengejar konsep pengeditan bebas-ruang ini untuk bahasa umum. Untuk XML / XSLT, bagaimanapun (karena perlakuan khusus spasi putih), tampaknya ada beberapa kesepakatan potensi setidaknya.

Edit - Produk Dikirim

Terlepas dari sentimen negatif yang umumnya ditemukan di sini, saya tetap pergi dan mengirim editor. Saya membuat versi gratis dengan harapan itu akan membawa kritik dalam bentuk masalah yang lebih konkret, berdasarkan pengalaman nyata. Agak frustasi, belum ada keluhan sejauh ini (bahkan hampir tidak ada umpan balik mempertimbangkan volume unduhan). Saya ingin berpikir ini karena pengguna menyesuaikan dengan ide dengan sangat baik sehingga mereka melihat ini sebagai 'jadi apa?' jenis fitur - tetapi tidak ada cara untuk mengatakan ...

Masalah terbesar adalah bagaimana file akan muncul ke alat lain, terutama alat kontrol versi. Akhir baris sangat penting untuk alat ini. Saya tidak ingin melihat layar menggabungkan di mana saya memiliki seluruh kelas dalam satu baris dan mencoba dan menggabungkan beberapa bagian dari teks di kolom 347.

Itu akan bagus. Emacs kurang lebih melakukan ini, dan sebagian besar melakukannya dengan benar. Sudahkah Anda mencoba mode nXML Emacs? Bagaimana Anda memperbaiki hal itu?

Anda tidak dapat membangun editor baru sampai Anda telah mencicipi apa yang sudah tersedia.

Bagaimanapun, lekukan harus disimpan dalam file output, sehingga file tersebut dapat dilihat dengan alat lain. Saya tidak akan mengadopsi editor baru kecuali jika mendukung kustomisasi run-time seperti Emacs.

Saya pernah melihat ide ini sebelumnya, tetapi saya belum pernah melihatnya benar-benar berhasil. Sebagian besar waktu, ketika saya telah melihat ide datang, sudah ditembak jatuh oleh setiap pengembang di luar sana - atau ketika telah dilaksanakan, itu membuat kontrol versi hampir tidak berguna hanya sebagai melihat kode dilipat akan mengubah file dan membingungkan lanjut alat diff. (Contoh betapa buruknya ini adalah Witango Development Studio.)

Saya dapat memikirkan beberapa rintangan yang harus diatasi oleh editor Anda agar bermanfaat bagi banyak pengembang:

• Perubahan pada file tidak boleh membuat suara berisik pada perintah * nix diff -uw. (Tidak ada perbedaan palsu!)
• Mengedit file (yang sebelumnya tidak diformat) tidak boleh menyulitkan penggabungan dalam alat SCM.
• Itu harus bermain dengan baik dengan editor lain yang digunakan oleh tim dev.
• Pengguna harus dapat menyesuaikan pemformatan dengan isi hati mereka - beberapa orang cukup bersemangat tentang bagaimana kode mereka muncul.
• Suntingan ke kode yang ada tidak boleh mengubah format yang ada. Sangat penting bahwa editor tidak tiba-tiba memformat ulang seluruh file tanpa alasan yang jelas dan tidak mengubah format baris untuk pengeditan kecil yang sederhana - yang akan membingungkan alat yang berbeda dan membuat marah anggota tim lainnya.
• Mungkin tidak boleh menghapus kelebihan spasi putih - mungkin akan membuat seseorang kesal . Lebih baik tidak mengambil risiko.
• Baris baru yang ditambahkan ke file harus sesuai dengan pengaturan modelines yang ada, atau harus sesuai dengan format lokal (dalam +/- 3 baris) yang ada.
• Editor harus memiliki panel pengaturan yang memungkinkan pengguna untuk menentukan kebijakan pemformatan kode tim yang terpisah dari apa yang sebenarnya ditampilkan oleh editor.

Tidak perlu dikatakan, jelas bahwa ini akan memerlukan sejumlah metadata tentang format file yang ada. Anda mungkin ingin memisahkannya dari sumber, tetapi tetap menyinkronkannya dengan repositori yang selalu berubah mungkin akan sangat sulit.

Sebagai pengguna Vim, saya juga berpendapat bahwa editor harus menghormati Vim, Emacs, dan modeline editor lainnya dan mempertahankan format terlarang modeline, terlepas dari apa yang akhirnya ditampilkan.

Menurut pendapat saya, persyaratan untuk perangkat lunak seperti itu membuatnya tidak bisa dipertahankan. Terlalu banyak pengguna akan berharap terlalu banyak untuk membuat proyek seperti ini berhasil.

Solusi, menggunakan file konfigurasi formatter berbasis teks (misalnya, XML):

• Memiliki pemformat pribadi yang dikonfigurasi oleh pengembang individu.

  • Simpan formatter ini secara lokal.

  • File dimuat dan diedit dengan format lokal.

  • Mereka dapat dengan bebas mengubah gaya pemformatan mereka tanpa merusak apa pun.

  • Pemformatan otomatis dapat dimatikan untuk menampilkan dan mengedit file mentah.

• Konfigurasikan pemformat tim minimal untuk standar tim.

  • Simpan formatter ini di kontrol versi tim.

  • File disimpan dengan pemformatan tim sebagai cadangan untuk alat lain.

  • Diffs tidak menderita masalah pemformatan.

Sangat konyol untuk khawatir tentang penghematan ekonomi file tanpa spasi kosong, jadi Anda tidak benar-benar kehilangan apa pun dengan menyimpan file dengan beberapa format yang ditentukan oleh standar tim. Dalam kasus pengembang solo, Anda dapat menawarkan kemampuan untuk menyimpan pemformatan (untuk "tim" satu) pemformatan yang ditampilkan di cermin.

Ketika formatter tidak mencukupi, Anda memiliki dua opsi yang aktif:

• Paparkan antarmuka untuk pemformat khusus.

  • Dilakukan dengan benar, ini adalah solusi terbaik.

  • Dilakukan salah, ini yang terburuk.

• Izinkan penggantian manual pemformatan otomatis.

  • Kegunaan tidak menderita — pertimbangkan Ctrl- (Enter | Tab | Space).

  • Sanity-di mana Anda menyimpan format ini? Apakah kamu?

Aku akan baik-baik saja dengan kode yang AUTOFORMATTED jika bahasa tidak memformat sensitif batuk Python batuk .

Emacs memang Lisp memformat benar-benar bagus, dan diformat dengan cepat aku akan sangat senang. Saya tidak tahan dengan penyisipan paren atau pembatas lainnya secara otomatis: tidak ada autoinserter yang pernah saya coba dekat dengan cara saya mengetik.

Saya menyukai ide dalam konsep . Dan sementara Anda mungkin berhasil, saya belum menemukan editor yang cukup melakukan semua yang saya inginkan untuk dilakukan dalam format. Berikut beberapa penghalang jalan (IMO):

• Bahasa pemilih pilih-pilih
• Apa yang disimpan ke output? (Anda akan, sampai taraf tertentu, harus menyimpan setidaknya beberapa indentasi agar tetap dapat dibaca oleh orang lain tanpa alat)
• Ini harus benar - benar bermain baik dengan produk kontrol sumber / versi yang sudah ada
• Itu harus sangat disesuaikan, terutama bagi kita (termasuk saya) yang sangat, sangat, sangat pemilih tentang bagaimana kode diformat dan indentasi (dan di mana koma itu harus masuk dalam daftar, tetapi jika daftar itu benar-benar panjang, bagaimana garis harus putus, dll.)
• Itu harus benar-benar mengerti bahasa. Maksud saya ini harus mengikuti bahasa persis seperti yang akan dipahami oleh kompiler. Saya memiliki terlalu banyak editor dengan sintaks berwarna yang membuat sintaks salah karena ada beberapa sisi bahasa yang tidak bisa ditangani dengan RegExp. Memang, Anda menunjukkan bahwa Anda akan terus mengurai bahasa, tetapi siapa yang mengatakan bahwa apa yang Anda parsing sesuai dengan kompiler yang saya gunakan? (Percayalah, ada banyak standar di luar sana, dan ada banyak bisnis lucu yang terjadi di sebagian besar bahasa, termasuk kode yang keliru dengan pengurai sederhana, tetapi sangat tepat untuk kompiler.)
• Itu harus cepat . Dan di sinilah karet bertemu jalan - Anda tidak dapat melakukan kompilasi penuh pada kode saya setiap keystroke (terutama dengan proyek besar), kecuali Anda dapat mengoptimalkan parser Anda ke tingkat N. Jika ada sedikit kelambatan di editor, tidak ada yang akan menggunakannya. (Saya adalah contoh sempurna untuk meninggalkan editor lambat demi yang lebih cepat. Jika paling lambat, saya keluar.)

Bisakah Anda membuat sesuatu yang memenuhi sebagian besar kriteria dengan cukup baik? Mungkin. Tapi kami programmer yang rewel dan pilih-pilih dan benci untuk berubah dan akan melompat-lompat pada tanda pertama masalah. Di sini Anda akan kesulitan jika output mencentang orang lain di tim dev, atau jika tidak bermain 100% baik dengan sistem versi, atau jika tidak memformat kode saya persis begitu atau jika salah paham bahasa dan salah-indentasi kode saya, atau jika tertinggal milidetik di luar apa yang saya harapkan. Karena, sepenuh hati saya idenya, saya akan melompat ke editor pilihan saya dalam sekejap.

Ada bahkan pendekatan yang lebih radikal - editor semantik murni. IDE berurusan dengan kode yang bahkan direpresentasikan secara internal sebagai AST, bukan teks biasa. Lihat JetBrains MPS misalnya.

Sekarang saya telah menerbitkan editor XML yang dijelaskan dalam pertanyaan saya, saya berada dalam posisi yang lebih baik (tetapi tidak ideal) untuk mencoba menjawabnya sendiri - jadi saya akan:

Setelah lebih dari 500 unduhan dalam waktu kurang dari 2 minggu, reaksi terhadap konsep baru yang mengejutkan ini dalam pemformatan kode dinamis telah ...

NOL

Tidak ada keluhan, tidak ada pujian. Interpretasi saya (harapan) tentang ini adalah bahwa orang hanya ingin dan mengharapkan editor yang terasa normal dan tidak mengacaukan kode mereka. Pengguna hampir tidak akan menyadari bahwa pemformatan mereka sepenuhnya virtual dan bukti menunjukkan bahwa mereka sangat peduli.

Ini akan menjadi kesalahan meskipun terlalu banyak membaca non-reaksi ini, alat ini gratis, dan sayangnya ini berarti setidaknya beberapa pengguna akan cenderung untuk mengkritik. Jika mereka tidak menyukainya, mereka mungkin hanya membuangnya dan menggunakan sesuatu yang lain.