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

8

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

Pengembang telah menetapkan alat dan metode kerja yang secara efisien mengatasi sebagian besar kerugian yang melekat dalam penggunaan karakter padding yang digunakan untuk indentasi.
Ada kekhawatiran bahwa penghapusan karakter pemformatan akan berdampak buruk pada beberapa alat yang berbeda.
Pengembang menginginkan fleksibilitas untuk memformat 'fine-tune' sedemikian rupa sehingga rendering otomatis tidak dapat menangani.
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.
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 ...

— pgfearo
sumber

saya pikir beberapa editor Skema melakukan pemformatan seperti ini dengan cepat, tetapi memasukkan (dan menghapus) spasi yang sebenarnya

— Javier

@Javier Saya harus akui saya belum menemukan Skema - Saya akan melihat ini, pandangan saya adalah bahwa ada beberapa bahasa di mana pemformatan lebih kritis / berbahaya daripada yang lain, jadi Skema mungkin salah satunya

— pgfearo

Saya sarankan Anda melihat Firebug dan bagaimana mengedit pohon HTML.

— Lie Ryan

@Lie Ryan - Ya, saya suka editor pohon, sejauh ini. Tapi itu masih terasa seperti Anda mengisi formulir daripada teks aliran bebas, saya kira itu karena hanya mengedit atribut, bukan elemen (dalam mode ini, sejauh yang saya tahu).

— pgfearo

HTML sebenarnya bukan teks alur bebas, tapi saya mengerti maksud Anda dengan merasa seperti mengisi formulir (pada kenyataannya itu sebabnya saya menyukainya, pembatasan membuatnya tidak mungkin untuk secara tidak sengaja memperkenalkan tag yang tidak tertutup / tidak cocok, atribut yang tidak dikutip, dll; Saya tidak akan menggunakan editor XML khusus jika memungkinkan saya untuk menulis XML yang tidak terbentuk dengan baik). Di Firebug Anda dapat menambahkan simpul baru dengan klik kanan> edit HTML, cukup merepotkan tetapi cukup untuk pengeditan kecil yang dibutuhkan pengembang web. Dalam editor yang lebih serius, dimungkinkan untuk memiliki tombol / menu konteks / cara pintas untuk memasukkan node.

— Lie Ryan

6

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.

— Jeremy
sumber

1

@ Jeremy - untuk memperjelas, semua umpan baris (jika ada) dipertahankan hanya dengan tab / spasi yang dihapus. Saya berharap alat yang berbeda dapat mengatasi jika ini hilang.

— pgfearo

1

Beberapa kontrol versi dan alat diff menawarkan opsi untuk mengabaikan perbedaan spasi putih.

— FrustratedWithFormsDesigner

1

+1 - Saya tidak dapat melihat manfaatnya, semua yang akan dilakukan adalah mengacaukan kontrol versi dan alat-alat yang berbeda.

4

@pgfearo Masalah yang saya miliki dengan sesuatu seperti ini adalah bahwa itu akan menjadi hampir hebat, tetapi <1% dari perubahan yang saya tidak ingin buat bahwa editor melanjutkan dan perubahan bagaimanapun akan menjengkelkan . Editor Anda harus sepenuhnya dapat disesuaikan ke tingkat ke-sembilan untuk memastikan bahwa itu memenuhi kebutuhan semua orang.

— Michael Todd

1

@pgfearo - pemformatan xml, ya, ini jelas merupakan pendekatan yang harus diambil, tapi saya pikir itulah cara sebagian besar editor memformat xml.

4

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.

— kevin cline
sumber

Mengapa lekukan harus diselamatkan, haruskah kita memaksakan format kita pada orang lain? Apakah orang masih menggunakan alat yang tidak memiliki plug-in XML, yang dapat memformat XML sesuai kebutuhan mereka (bukan milik penulis)?

— pgfearo

Di Emacs. Saya hanya menggunakan Emacs cukup lama untuk mengetahui bahwa saya tidak punya waktu (kemudian) untuk mempelajarinya dengan benar untuk melakukannya dengan adil. Saya menduga pengguna Emacs akan sama-sama sulit didorong untuk mencoba 'cara lain'. Saya akan melihat Emacs lagi, tapi saya khawatir tentang 'sebagian besar sudah benar' - Anda dapat memperbaikinya.

— pgfearo

@pgfearo disebutcat

— alternatif

@ mathepic mudah-mudahan * pengembang baris perintah nix memiliki akses ke xmlsh atau yang serupa?

— pgfearo

@pgfearo Jujur saya belum pernah mendengar tentang itu dan tidak akan pernah menggunakan shell yang disediakan untuk xml;)

— alternatif

3

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.

— greyfade
sumber

Jadi sepertinya kami terjebak dengan solusi kami saat ini, bukan karena itu yang terbaik, tetapi karena itu terlalu sulit untuk diubah. Sedihnya, ini benar di banyak bidang TI sehingga bodoh / sombong kalau saya merasa saya bisa memperbaikinya sendiri. Karena saya agak keras kepala saya masih akan menggunakan konsep ini terintegrasi sebagai alat opsional dalam solusi desktop yang jauh lebih besar di mana pemrosesan / analisis adalah perhatian utama. Dengan begitu pengembang memiliki pilihan.

— pgfearo

@pgfearo: Tidak, saya pikir kita "terjebak" dengan situasi kita saat ini, bukan karena itu yang terbaik, tetapi karena tidak ada yang lebih baik. Untuk memenangkan ide pengguna Vim dan Emacs, Anda harus memberikan manfaat yang substansial atas alat yang sudah efisien yang mereka gunakan. Untuk memenangkan semua orang, Anda hanya perlu menyediakan fitur yang sudah dinikmati pengguna Vim dan Emacs untuk audiens yang lebih luas. Tunggu, mungkin lisensi TextMate itu sepadan.

— greyfade

@pgfearo: Poin keseluruhan saya adalah saya pikir Anda tidak akan pernah mencapai sesuatu yang ingin digunakan siapa pun di atas alat yang ada, kecuali untuk sebagian kecil dari pekerjaan yang kami lakukan. Ada manfaat yang jelas bagi peretas XML dan XSLT, karena struktur adalah 99% pekerjaan, tetapi ada jauh lebih sedikit manfaat yang jelas untuk bahasa yang kurang terstruktur seperti C, Java, C #, Ruby, dll. Ini adalah penjualan yang sangat sulit ke hard -inti.

— greyfade

Ya, poin tentang alat / metode efisien yang ada ini adalah # 1 dalam kesimpulan (sementara) yang diedit untuk pertanyaan. Dari apa yang sudah dikatakan, saya ragu saya bahkan harus berusaha untuk memenangkan pengguna Vim / Emacs - jika ada minat dalam hal ini akan datang dari tempat lain.

— pgfearo

Menerima jawaban ini karena memecah masalah dengan singkat dan sejalan dengan sentimen umum dari jawaban / komentar lain. Bukan jawaban yang saya harapkan, tetapi itu membantu meyakinkan saya, bahwa - setidaknya untuk lingkungan non XML / XSLT - tidak ada gunanya mengejar konsep ini lebih jauh, tidak perlu membuang usaha lebih lanjut.

— pgfearo

2

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?

— Jon Purdy
sumber

Poin yang berguna. Saya suka gagasan memiliki file konfigurasi pemformat bersama. Pemformatan otomatis sudah dapat dialihkan dalam prototipe - karena ini penting untuk mengisolasi ruang nyata 'nyata' dari hal-hal virtual. Beralih di antara tampilan tentu saja tidak mengubah satu karakter. Kecenderungan saya bukan untuk menyediakan opsi di dalam alat untuk menyimpan 'dengan pemformatan' tetapi sebaliknya untuk memberikan 'adaptor' yang gratis, lintas platform dan juga dapat berjalan sebagai layanan web, ini dapat menggunakan file konfigurasi formatter XML yang sama kamu menyarankan.

— pgfearo

2

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.

— Paul Nathan
sumber

Ya, saya pikir F # juga menggunakan format dalam sintaksnya. Penyisipan otomatis pembatas adalah masalah. Untuk XML ini berupa menambahkan tanda kutip dll. Ini tidak sempurna tetapi mengompensasi pengetik sentuh yang mungkin akan berada di depan balapan, sehingga memeriksa bahwa sesuatu yang diketik belum diantrekan untuk penyisipan otomatis lagi pula - menghindari pengulangan. Tanpa penyisipan otomatis, parser dibiarkan menebak bagaimana cara indentasi - ia dapat menunda sedikit, tetapi akan ada beberapa 'jiggling' margin ketika parser mencoba memahami maksud sebenarnya dari kode yang sedang diketik.

— pgfearo

@pgfearo: fortran, cobol, f #, haskell, python, make, dan beberapa sistem lainnya dibatasi oleh spasi. Ini agak konyol IMO, karena melumpuhkan alat otomatis dalam operasi mereka (dan penguraian pengguna), tapi, yah, kita terjebak dengan mereka.

— Paul Nathan

2

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.

— Kerri Shotts
sumber

Pada titik Anda pada kinerja: daya tanggap dapat dibandingkan dengan alat yang ada. Karena pemformatan tidak berpengaruh pada teks kode, pemrosesan dapat berjalan di latar belakang dan diakhiri sesuka hati. Dengan XSLT, ada pendekatan kaskade, pemformatan / pewarnaan dilakukan sebelum validasi butiran halus dan kompilasi ultimat. Karena semua ini terjadi pada utas latar dan terputus segera pada keystroke berikutnya, tidak ada kelambatan kinerja yang jelas. Hanya teks yang terlihat yang perlu disegarkan segera, teks yang tersisa diformat ulang dalam semburan yang terpotong ketika ada jeda.

— pgfearo

Apa yang disimpan ke output? Tidak memformat secara langsung, karena ini akan memaksakan gaya pemformatan pada orang lain. Idenya (sebagai tanggapan terhadap jawaban sebelumnya) adalah untuk menyediakan formatters pluggable yang menggunakan file konfigurasi standar menyatakan aturan format dan output sesuai, sesuai permintaan.

— pgfearo

1

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.

— Logika SK
sumber

Ini menarik. Saya belum sepenuhnya memahami pendekatan MPS, tetapi desain untuk editor ini menggunakan AST yang setara dengan peta ke posisi dalam XML teks biasa. Jadi, setiap kali ada interaksi pengguna dengan teks biasa, editor segera tahu bagian mana dari 'AST' yang sedang diedit. Ini membantunya menentukan apakah reparsing diperlukan, dan juga membantu melindungi bagian-bagian pohon dari penghapusan yang tidak disengaja, ketika pengguna melakukan penghapusan 'tekan dan tahan', misalnya. Ini juga digunakan untuk menyajikan data tentang pemilihan saat ini secara real time. Saya akan melihat MPS lebih lanjut.

— pgfearo

0

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.

— pgfearo
sumber