Apa kekurangan dari tabstop elastis? [Tutup]


83

Lihat di sini: perang suci khas pada tab vs spasi .

Sekarang lihat di sini: tapstop elastis . Semua masalah terpecahkan, dan banyak perilaku baru yang sangat berguna ditambahkan.

tabstop elastis

Apakah tabstop elastis bahkan disebutkan dalam diskusi tab vs ruang? Kenapa tidak? Apakah ada kelemahan pada ide tabstop elastis yang begitu serius sehingga tidak ada yang pernah mengimplementasikannya dalam editor populer?

EDIT : Saya minta maaf karena terlalu banyak menekankan "mengapa mereka tidak disebutkan". Bukan itu yang saya maksudkan; yang dimaksud adalah mungkin bahkan off topic. Apa yang sebenarnya saya maksudkan adalah, apa kelemahan terbesar dari hal ini yang mencegah adopsi yang lebih luas dari ide yang jelas bermanfaat? (di dunia ideal di mana semuanya mendukungnya)

(Ternyata sudah ada permintaan di Microsoft Connect untuk implementasi Visual Studio dari elastis tabstop , dan permintaan di Eclipse juga. Ditambah ada pertanyaan tentang editor lain yang menerapkan elastis tabstop )


4
Ini akan menjadi pertanyaan yang bagus untuk ux.stackexchange.com
JonnyBoats

11
Mereka tidak pernah disebutkan dalam diskusi "tabs versus space" karena hampir tidak ada cara bagi programmer yang bekerja untuk menggunakan hal-hal ini. Mungkin jika Anda memiliki implementasi Eclipse, VS, gvim dan emacs, itu mungkin berubah.
Paul Tomblin

2
Saya sangat menyukai ide itu, tetapi hanya ketika Anda hidup dengannya selama sebulan atau lebih sehingga Anda benar - benar tahu apa jebakan itu. Seperti segalanya, dijamin ada beberapa kasus di mana ia melakukan hal-hal yang tidak Anda harapkan ...
Chris Burt-Brown

3
@ ChrisBurt-Brown Itu selalu berisiko, ya. IntelliSense juga memiliki jebakannya, seperti mengganti teks saat Anda tidak menginginkannya. Namun secara keseluruhan, IntelliSense di C # merupakan kemenangan besar.
Roman Starkov

4
Saya ingin ini di notepad ++ ... Saya ingin ini sekarang
Ben Brocka

Jawaban:


32

Perang Suci itu Subyektif

Tabstop elastis Nick adalah konsep luar biasa yang dapat membantu banyak orang menyetujui solusi yang bisa diterapkan, meskipun saya sangat ragu itu akan mengakhiri Perang Suci ini: lagipula, ini juga masalah selera dan banyak programmer tidak akan memindahkan inci dari posisi mereka tentang masalah ini, bahkan dengan mengorbankan kompromi. Jadi itu akan menjadi alasan pertama.

Misalnya, banyak orang di sisi "spasi" masih akan membencinya karena memerlukan bagian logika tambahan dalam perangkat lunak Anda untuk rendering yang layak (misalnya hanya melihat perubahan di tampilan web SCM Anda).

Masalah Implementasi

Tetapi alasan yang paling jelas hanyalah hambatan teknis untuk masuk : itu adalah konsep yang pada dasarnya berbeda dari apa yang telah diterapkan selama beberapa tahun (jika bukan beberapa dekade) dalam IDE dan editor teks. Diperlukan untuk menulis ulang beberapa dari mereka untuk memproses garis dalam fasion yang cukup berbeda, yang menyulitkan sistem yang lebih tua dan lebih besar yang memiliki peluang lebih tinggi untuk menderita kopling dalam dan ketat dalam kode pemrosesan baris mereka. Hal ini, bagaimanapun, jauh lebih mudah untuk dilakukan ketika Anda mulai dari awal (memikirkan demo Nick atau Go 's tabwriter paket).

Untuk sebuah anekdot pribadi, saya ingat mendekati penulis beberapa waktu lalu untuk menanyakan apakah ada dukungan emacs yang terlihat, dan dalam kasus khusus ini ia menyebut ini sebagai alasan untuk tidak sepele. Dia juga meminta bantuan dari komunitas untuk membantu mengimplementasikan fitur ini dan membawanya ke massa.

Apakah Kita Cukup Peduli?

Alasan ketiga, adalah bahwa beberapa pengembang tidak terlalu memahami masalah ini dan tidak terlalu peduli sehingga mereka akan berusaha keras untuk mendukung upaya tersebut. Dalam kebanyakan kasus, konflik spasi-vs-tab bukanlah pemblokir bisnis, jadi tidak ada banyak dorongan di balik masalah ini.

Jika Anda menginginkannya, Anda harus berjuang untuk itu. Yang bisa dilakukan dalam perangkat lunak sumber terbuka. Dan jika Anda cukup mengubah ini, sumber tertutup harus mengikuti dengan risiko kehilangan sebagian pengguna mereka, jika sebagian kecil darinya.

Jadi, jika Anda menginginkannya, bantu Nick.


(diluar topik) Saya sering bertanya-tanya bagaimana fitur "ini bagus tapi sangat kecil" yang pernah membuatnya menjadi produk seperti Visual Studio. Tampaknya seseorang dalam tim baru saja menemukan waktu untuk mengimplementasikannya karena alasan pribadi. Pikirkan mengetik beberapa baris sekaligus di Visual Studio, misalnya; tidak seperti puluhan ribu orang yang memintanya, tetapi saya lebih menyukainya.
Roman Starkov

3
@romkyns: Untuk banyak hal, dibutuhkan satu orang dalam yang tenang atau seribu suara yang berteriak di gerbang.
haylem

35

Sering kali saya harus berkelahi dengan pengolah kata untuk mendapatkan dokumen agar terlihat seperti yang saya inginkan tanpa aturan otomatis tersembunyi yang mengendalikan penempatan kata-kata saya. Saya tidak ingin menghabiskan waktu satu detik untuk mencari tahu mengapa editor bersikeras untuk menempatkan kata-kata itu di sana.


11
Saya juga tidak. Saya sepenuhnya bersimpati dengan sentimen ini, karena aturan seperti itu benar-benar membuat saya frustrasi juga. Tetapi ini berbeda dalam dua cara. Satu: Sama seperti tabstop sekarang, Anda tidak harus menggunakannya jika tidak mau. Anda dapat membiarkan teks kolega Anda sendiri jika menggunakannya. Dua: Tabstop elastis tidak memiliki aturan tersembunyi, tetapi yang jelas-jelas jelas. Perilaku ini benar-benar alami - mungkin bahkan lebih alami daripada tabstop tradisional, yang terjadi pada posisi yang sewenang-wenang, biasanya tidak relevan, dalam teks. Inilah sebabnya mengapa tidak ada yang menggunakan tabstop untuk apa pun selain lekukan lagi.
Timwi

10
@Timwi: Pertanyaannya adalah daftar kekurangannya. Aku melakukannya.
mhoran_psprep

14
Mungkin tidak jelas dari GIF, tetapi satu-satunya yang diketahui adalah ketika Anda menekan "TAB", apa pun yang muncul setelahnya akan keluar dengan benar secara vertikal. Tidak seperti pengolah kata. Coba saja demo interaktif aktual di tautan yang saya poskan, dan Anda akan melihat betapa alami itu.
Roman Starkov

3
@ mhoran_psprep: Cukup adil, saya menghargai masukan Anda. Saya kira kita melihat interpretasi yang berbeda dari pertanyaan itu. Anda membuat daftar kelemahan diri Anda menggunakan fitur, sementara saya pikir itu tentang kelemahan memperkenalkan fitur (yaitu membuatnya tersedia dan tidak wajib ).
Timwi

27

Ini adalah pertama kalinya saya mendengar itu. Tidak yakin apakah itu ide yang bagus tetapi tampaknya tidak banyak digunakan karena kami memiliki alat (seperti indentasi) yang sudah memformat kode secara otomatis.

Apa yang terjadi ketika saya membuka tabstop elastis pintar Anda di vim dan mengeditnya? Apakah tab secara otomatis dibersihkan atau Anda dibiarkan berantakan?

Kelemahan utama, seperti yang saya lihat mereka mungkin melanggar diff, kontrol versi, dan tidak kompatibel dengan editor yang tidak mendukungnya. Ini mungkin banyak modifikasi kode untuk mendukung mereka dan ada hal-hal yang lebih penting daripada fitur "hal lain untuk memformat kode". Lagi pula, kita semua dapat menggunakan indentyang melakukan semua hal di atas jika memori berfungsi.


9
Sungguh sikap berpikiran mundur. Mari kita tidak ada kemajuan karena favorit tua, alat usang orang tidak dapat mengatasi dulu ! (Ironisnya, tentu saja, adalah bahwa alat-alat ini (seperti vim) adalah open-source, jadi jika itu benar-benar penting bagi Anda, Anda bisa (dan mungkin harus ) menambahkan dukungan tabstop elastis untuk itu)
Timwi

14
@ Timwi: Anda benar-benar kehilangan poin yang saya buat. Apa yang terjadi ketika file kode Anda diurai oleh sesuatu yang tidak menyadari tabstop elastis? Apakah Anda berakhir dengan kekacauan atau dapatkah mereka mengatasinya? Bagaimana dengan kontrol dan perbedaan versi? Hanya berharap bahwa semua alat mendukung fitur $ tidak realistis bahkan jika alat tersebut adalah open source.
Sardathrion

14
@Timwi: Anda berasumsi bahwa semua orang menemukan tapstop elastis sama kerennya dengan yang Anda pikirkan. Ini mungkin tidak benar.
Sardathrion

7
@Sathathrion benar. Apa yang terjadi ketika saya harus remote ke server * nix saya tanpa sistem windowing dan perlu memeriksa beberapa kode dengan Vim / Emacs / Pico / Terserah? Jika ada mekanisme sehingga bisa dibaca itu akan baik-baik saja ... kalau tidak, itu akan menjadi mimpi buruk. Saya tidak melihat manfaat dari tab elastis menjadi bermanfaat. Saya sudah bisa autoformat kode saya untuk melihat bagaimana seharusnya dalam IDE yang saya gunakan.
Rig

7
Titik kontrol versi adalah yang baik - saya tidak berpikir orang akan menghargai editor yang diam-diam mulai mengubah penempatan / format komentar dalam kode yang secara sewenang-wenang jauh dari kode yang mereka modifikasi (lihat bagian magenta dalam animasi OP) gif). Akan sangat membantu untuk memiliki implementasi referensi untuk dimainkan, tetapi apa yang saya lihat sejauh ini tidak luar biasa - emacs sudah melakukan banyak hal ini, hanya dengan beberapa penekanan tombol tambahan (yang bisa dibilang adalah hal yang baik).
mcmcc

13

Sejujurnya, saya tidak menemukan mereka yang berguna setelah Anda mengatasi kegembiraan awal. Misalnya, saya tidak suka komentar di akhir baris - saya selalu meletakkan komentar saya di baris terpisah. Dengan itu, tab elastis kehilangan penggunaan utama mereka.

Setelah itu, Anda tentu saja masih dapat menggunakannya untuk menyelaraskan argumen fungsi (dan parameter) dan daftar tugas yang panjang.

Tetapi untuk yang pertama saya cenderung hanya membuat indentasi semua argumen dengan satu tingkat tambahan dan itu berfungsi baik-baik saja dengan saya:

void foo(
    int x,
    int y,
    string z
)

Dan saya tidak melihat ada kebutuhan untuk mengubahnya.

Dan untuk menyelaraskan tugas, saya tidak melakukan itu. Saya menempatkan satu spasi di sekitar tugas, itu saja. Saya juga cenderung tidak mengelompokkan banyak tugas bersama sehingga jarang ada masalah keterbacaan.

Singkatnya, tab elastis sama sekali nol kegunaan bagi saya. Ini tentu saja merupakan preferensi yang sangat pribadi yang dapat bervariasi tetapi saya menemukan bahwa itu bekerja dengan baik dan saya kira kurangnya dukungan untuk tab elastis adalah karena orang lain berpikiran sama.

Jika seorang editor akan mengimplementasikannya, saya masih tidak akan menggunakannya.


Dihargai Tampaknya Anda dapat menggunakan font lebar variabel dengan senang hati juga jika Anda ingin, karena Anda tidak menyelaraskan apa pun selain awal baris. Visual Studio memiliki dukungan yang cukup bagus untuk ini, sebenarnya, dan peningkatan keterbacaannya bagus.
Roman Starkov

1
@romkyns Kami memiliki diskusi tentang itu dan dalam perjalanan satu saya mencoba menggunakan font yang proporsional untuk pemrograman untuk beberapa waktu. Hasilnya adalah font monospace bekerja lebih baik, bahkan ketika mengabaikan lekukan. Terlepas dari itu, saya saat ini bekerja secara eksklusif di Vim dan konsol, yang keduanya kemungkinan besar tidak akan mendukung font proporsional.
Konrad Rudolph

1
@romkyns Yang mengatakan, masalah ini dapat dipecahkan (atau mungkin bahkan diselesaikan, dengan font proporsional yang dirancang untuk pemrograman). Tapi saya masih belum benar-benar melihat perlunya.
Konrad Rudolph

13

Salah satu kelemahannya adalah ia tidak berfungsi jika Anda ingin menyelaraskan pada satu kelompok garis dan kemudian lekukan pada yang berikutnya, karena mengelompokkan tab berhenti dari garis yang berdekatan.

def foo( bar,
         xyzzy ):
         wibble() # Too much indentation

Apa yang saya inginkan:

def foo( bar,
         xyzzy ):
    wibble()

Untuk bahasa penjepit keriting, ini mungkin tidak terlalu menjadi masalah, karena Anda biasanya dapat menyelesaikannya dengan meletakkan penjepit pembuka pada garisnya sendiri (seperti dalam animasi), tetapi untuk bahasa yang peka spasi ruang angkasa, ini dengan cepat menjadi masalah, dan Anda akhirnya harus kembali menggunakan spasi.


Sepakat. Implementasi Nick sama sekali tidak berfungsi untuk bahasa seperti Python.
Roman Starkov

3
Mengapa ini tidak berhasil? Ini bukan batasan mendasar, algoritma hanya perlu sadar bahasa. Tetapi sampai taraf tertentu ini benar bahkan hingga hari ini, Vim misalnya mendefinisikan aturan indentasi yang berbeda tergantung pada bahasanya. Ini dengan mudah dapat mengakomodasi lekukan Python.
Konrad Rudolph

1
@KonradRudolph Tidak, mereka tidak bisa. Yang menarik dari elastis tabstop adalah kemampuan untuk secara otomatis indent / unindent kelompok teks bersama. Salah satu contoh sederhana adalah akhir dari pernyataan "jika": Anda mencoba dan membatalkan indentasi karena Anda keluar dari pernyataan tersebut, tetapi tabstop elastis "pintar" memutuskan bahwa Anda bermaksud juga membatalkan indentasi baris atau dua baris di atas, begitu seterusnya dan sebagainya ... Dan jika Anda harus secara eksplisit mengelompokkan teks bersama, lalu - apa gunanya? Lebih banyak pekerjaan untuk melakukan itu daripada memperbaiki indentasi sendiri ...
Izkata

1
@Izkata Penghindaran secara manual akan (harus) cukup mengakhiri grup saat ini. Mengapa Anda pernah mengontrol lekukan dengan tab elastis berhenti secara manual? Anda tidak akan melakukannya, jadi algoritme tahu bahwa ketika Anda melakukannya, ini untuk mengakhiri blok, bukan untuk menghapus inden pada blok di atas.
Konrad Rudolph

1
Oh, bagus. Hmm ... mungkin Anda bisa melipatgandakan indentasi argumen? Jadi wibble()hanya akan memiliki lekukan tunggal dan karena itu tidak akan selaras dengan argumen fungsi?
Ajedi32

12

Mengapa kita tidak membuat karakter tab vertikal saja (VT, ASCII 11) berfungsi untuk menunjukkan penggunaan tabstop elastis? Ini tidak ada gunanya dalam bahasa pemrograman utama apa pun, namun diuraikan sebagai spasi kosong yang valid di semuanya, AFAIK.

Ini berarti bahwa penggunaan tabstop elastis tidak lagi menjadi konvensi eksternal (mis. "File ini diformat dengan tabstop elastis, silakan nyalakan") tetapi sesuatu yang Anda pilih berdasarkan kasus per kasus.

Editor teks yang ada biasanya menampilkan mesin terbang atau ruang tunggal di tempat tab vertikal. Ini tidak ideal, tetapi harga yang harus dibayar, IMO.


10

Mereka tidak disebutkan karena mereka tidak diterapkan di sebagian besar IDE editor teks; mereka adalah hal baru yang jarang digunakan dalam suatu proyek.

Spasi telah digunakan untuk membuat program sejak zaman kartu punch. Tab datang dan seseorang jelas berpikir itu ide yang bagus (mereka keliru: p).

Pada hari-hari ketika sebagian besar editor modern dapat mengonversi tab menjadi spasi secara otomatis ... mereka tidak ada gunanya.

Harus menginstal alat lain untuk menangani sesuatu yang sepele seperti tab vs spasi tentu tidak menarik bagi saya, dan saya tidak berpikir itu akan terjadi pada sebagian besar rekan saya.


Saya sudah membersihkan komentar saat mereka turun ke penghinaan.
ChrisF

1
Hanya berpikir saya akan tunjukkan, alasan utama mengapa saya menyukai ide tabstop elastis bukan karena itu memecahkan masalah tab vs spasi, tetapi karena perilaku yang ditunjukkan dalam GIF dalam pertanyaan awal; otomatis, penyelarasan bebas rasa sakit. Plus, untuk VCS diffs ada manfaat tambahan bahwa tidak ada perubahan spasi putih yang diperlukan dalam contoh itu.
Ajedi32

"Harus menginstal alat lain ..." bukan argumen yang cukup bagus ... Seolah-olah tidak ada cukup alat yang digunakan.
Milind R

@ MilindR Apakah Anda menganggapnya argumen yang cukup baik atau tidak, itu adalah alasan mengapa (pada waktu tiga tahun yang lalu) saya tidak tertarik dengan ini. Ada banyak alat yang digunakan untuk melakukan sesuatu yang bermanfaat bukan alasan untuk menambahkan yang lain, sungguh, tidak menambahkan apa pun ke lingkungan Anda.
TZHX

Sikap seperti ini adalah mengapa perusahaan seperti MS memutuskan untuk memaksa pengguna ke UX baru ... Saya ngeri memikirkan apa yang akan terjadi jika sikap yang sama diterapkan pada disket -> transisi CD.
Milind R

4

Saya pikir mereka akan menemukan banyak kegunaan jika IDE mendukungnya (Microsoft!). Begitu orang menemukan mereka bisa menampar flowerbox mereka di samping dan membuatnya mudah dibaca, mereka akan melakukannya. Anda mungkin mendapat lebih banyak komentar yang ditambahkan ke kode sumber secara tiba-tiba (yang hanya bisa menjadi hal yang baik).

Saya kira kita juga bisa menambahkan komentar "tooltips" ke daftar 'apakah itu baik jika ...', jadi blok komentar besar Anda dapat disembunyikan dan dilihat dengan mudah saat dibutuhkan. Mungkin kita juga bisa memiliki blok komentar yang membentuk bagian dari dokumentasi (bukan barang jenis sandcastle, cuplikan dokumentasi yang dapat dibaca pengguna yang tertanam dalam kode, bukan hanya header metode)

Kekurangan: ini mungkin membuat sumber Anda berbeda terlihat buruk jika banyak baris tampak seperti mereka berubah ketika hanya 1 yang dimodifikasi (jika editor menyimpan file dengan tab yang dikonversi ke spasi). Atau, jika tab elastis diterapkan dengan satu karakter (atau lebih mungkin, 2 tabstop) maka melihat sumber Anda di luar editor bisa terlihat buruk.

Saya pikir saya suka gagasannya, 'tab tab' di akhir baris melemahkan blok komentar dan mengurutkan semua komentar pada baris berikutnya (yang memiliki spasi tab ganda).


3

Begini cara saya melihatnya: jika sebagian besar alat populer sudah mendukung tabstop elastis, banyak orang akan menggunakannya. Hal yang sama terjadi dengan mode navigasi / edit vi, dengan penyorotan sintaks, dan kemudian dengan Intellisense. Dalam setiap kasus, kebijaksanaan yang sudah mapan adalah bahwa itu tidak berguna atau tidak diperlukan, tetapi diterapkan dan lepas landas.

Tabstop yang elastis tentu saja memiliki dampak yang relatif rendah. Kebanyakan orang cukup senang dengan status quo dan karenanya tidak peduli. Alasan yang sama diterapkan pada banyak situasi di mana beberapa orang hanya senang dengan apa yang mereka dapatkan dan tidak melihat alasan untuk beralih ke sesuatu yang lebih maju. Dengan kata lain, masalah terbesar dengan tabstop elastis adalah sama dengan hampir setiap ide bagus lainnya: perlu mendapatkan daya tarik.

Tetapi itu tidak berarti fitur tersebut tidak dapat diadopsi secara bertahap. Setiap bahasa pemrograman tunggal diadopsi secara bertahap, meskipun seluruh tim membutuhkan kompiler baru dan IDE baru untuk mulai menggunakannya. Hal yang sama berlaku untuk setiap arsitektur perangkat keras tunggal dan banyak contoh lainnya. Ini juga bukan kasus bahwa kurangnya integrasi dengan alat-alat yang ada adalah show-stopper: hal yang sama berlaku, misalnya, "format unified-diff", yang secara bertahap menggantikan format yang sebelumnya kurang dapat dibaca yang tetap dipahami oleh alat otomatis (seperti tambalan). Alat-alat itu telah ditingkatkan dari waktu ke waktu.

Saya menghargai masalah interop yang telah disebutkan orang lain, tetapi meskipun ada, pasti akan ada tim (seperti milik saya) yang akan mengadopsi ini tanpa ragu-ragu, secara keseluruhan. Alat eksternal seperti pembedaan, penggabungan dll. Pada awalnya tidak akan mendukungnya, tetapi kami akan melakukan bagian kami untuk mendorong vendor untuk memasukkan fitur tersebut. Inilah bagaimana kemajuan selalu dibuat. Ini membutuhkan beberapa rasa sakit untuk periode transisi sementara, tetapi pada akhirnya, itu sangat berharga.


Argumen C vs C ++ tampak agak salah arah. Walaupun mungkin benar bahwa ini adalah kasus untuk "beberapa orang" (seperti yang Anda katakan dengan benar), ada alasan yang jelas untuk tetap menggunakan C atau mendukung C ++ tergantung pada situasinya. Ukuran runtime C ++ menjadi salah satunya, dalam pengaturan default.
haylem

Saya dengan haylem. Poin Anda akan lebih baik tanpa perbandingan C-versus-C ++. Mereka adalah bahasa yang sangat berbeda. Menurut saya, C adalah untuk pemrograman sistem dan pekerjaan tingkat rendah lainnya di mana Anda memerlukan banyak kontrol (misalnya VM). C ++ lebih untuk aplikasi tingkat menengah di mana abstraksi berguna untuk mengelola kompleksitas (ruang nama, wadah STL dan algoritma, templat), tetapi kinerja masih menjadi perhatian (game menjadi contoh yang paling terlihat).
Jon Purdy

@haylem: Terima kasih atas umpan baliknya. Saya telah menghapus referensi ke C / C ++.
Timwi

@ JonPurdy: Terima kasih atas umpan baliknya. Saya telah menghapus referensi ke C / C ++.
Timwi

2

Masalah terbesar yang saya miliki dengan itu adalah jarak yang tidak konsisten di seluruh dokumentasi. Saya tahu sebagai seorang programmer saya akan kesal melihat loop atau jika pernyataan pada lekukan 'standar' dan kemudian melihat di lekukan yang berbeda. Saya tahu secara pribadi saya suka melihat semua kurung kurawal saya di sepanjang dokumentasi, tidak hanya di blok kode yang saya lihat.

Secara keseluruhan saya pikir itu ide yang bagus, tetapi secara pribadi, saya tidak akan menyukainya.


1

Saya baru saja mencoba implementasi elastis tabstop jEdit, yang bekerja sangat baik dengan bahasa pemrograman yang saya kenal (terutama bahasa HTML / XML dan bahasa mirip-C). Namun, dengan kode Python, inilah yang ditampilkan (spasi digunakan sebagai pengganti tab untuk mengilustrasikan bagaimana berbagai hal menyelaraskan):

def foo(x):
             '''<1 tab before the docstring.
No tab       <tab
No tab       <tab
             <tab  <another tab
             <tab  <another tab
             <tab'''
             if 1 or 2:    #<Tab before this comment
                           yield True

Untuk bahasa seperti Python yang bergantung pada spasi, ini adalah pemecah kesepakatan kecuali Anda menonaktifkan fungsi yang disediakan oleh tabstop elastis. Editor seperti Vim dan Emacs membuat penonaktifan sebagian besar fungsi menjadi sederhana jika Anda tahu nama opsi dan cara menonaktifkannya, tetapi fungsi ini harus dinonaktifkan untuk kode seperti di atas.

Yang sedang berkata, itu bagus untuk x86 ASM, C, C ++, Go, XML, HTML, dan lainnya yang tidak terlalu bergantung pada spasi putih:

import (
    "fmt"    // We love formatting functions.
    "io"     // Because I/O is useful.
    "os"     // Can't open a file without os.Open!
)

type Foo struct {
    Field1              int          // This is properly aligned
    ReallyLongField2    string       // with this.
    privateField        io.Reader    // Elastic tabstops are great for Go.
}

Saya akan mengatakan bahwa dialek Lisp seperti Skema memiliki konvensi mereka sendiri yang juga akan membuat tabstop elastis membuat kode "jelek". Jika saya mengubah pengaturan tabstop untuk mencocokkan konvensi 2 kolom dan menyisipkan tabstop di tempat yang tidak biasa (antara fungsi dan argumennya):

(let loop ((n 1))
  (if  (> n 10)
        '()
        (cons  n
               (loop (+ n 1)))))

vs. yang lebih mudah dibaca:

(let loop ((n 1))
  (if (> n 10)
      '()
      (cons n
            (loop (+ n 1)))))

Memang, yang ini tidak seburuk contoh Python, tetapi jelas mengurangi keterbacaan kode. Sementara saya sangat menikmati fungsionalitas ketika coding dalam sesuatu seperti C # atau C ++, saya benci fungsionalitas ketika coding dalam bahasa seperti Python atau Skema di mana spasi putih berfungsi dan / atau bermanfaat secara visual. Tabstop elastis dibuat secara khusus untuk membantu tanpa memerlukan utilitas indentasi yang terpisah, tetapi jelas itu tidak dimaksudkan untuk semua bahasa pemrograman.


0

Emacs sudah menangani lekukan di hadapan tanda kurung tertutup, dan secara otomatis akan menyelaraskan wilma dengan fred . Saya tidak tahu mengapa Eclipse tidak melakukan hal yang sama. Oke, saya punya ide, tapi tidak gratis.

Anda bisa membuat Emacs menyelaraskan komentar juga, tanpa banyak kesulitan, tetapi AFAIK tidak seorang pun kecuali Anda pernah menginginkannya.


2
Saya hanya bisa menafsirkan kalimat terakhir Anda sebagai trolling, karena jelas setidaknya satu orang lain sangat menginginkannya untuk membuat halaman yang diperdebatkan dengan baik, implementasi Java dan GIF untuk menunjukkan mengapa itu bagus. Jika Anda membaca jawabannya, Anda akan menemukan bahwa Nick juga tidak sendirian. Oh, tunggu, lihat di sini juga.
Roman Starkov

Omong-omong, apakah Emacs indentasi ulang wilmasaat Anda mengedit, seperti mengubah panjang nama fungsi? Jika ya, itu cukup dekat dengan apa yang dilakukan oleh tabstop elastis.
Roman Starkov

@romkyns: Saya tidak bermaksud melakukan troll, saya hanya bermaksud bahwa saya belum pernah melihat gaya komentar yang menjorok dalam EMACS. Umumnya EMACS tidak mengindentasi ulang beberapa baris saat Anda mengetik, tetapi itu bisa diubah juga.
kevin cline
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.